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?

With annotations covering read-only/open-world/destructive, the description adds substantial behavioral detail: the exact return envelope, parse_status values, null-field and null-data behavior, 400 and 500 error conditions, and pricing rules including that failed fetches are not charged. This goes well beyond what annotations alone provide.

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 front-loaded: purpose, supported examples, return shape, error handling, alternative, and pricing follow in order. Every sentence carries operational information, and there is no filler or repetition.

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, open-world tool with no output schema and six parameters, the description supplies the return structure, status semantics, failure behavior, cost model, and sibling routing. It gives the agent everything needed to decide whether and how to call it.

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 that provider and type are detected from the URL, but it does not add parameter-level meaning beyond the schema, nor does it discuss country, transcript, or sandboxing options.

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: 'Get structured JSON for a public page on a supported site from its normal URL.' It enumerates supported providers and page types, and explicitly names the sibling for unsupported sites ('use webscraping_ai_fields'), making it easy to distinguish from alternatives.

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 the condition for use (supported site, normal URL) and gives an explicit alternative for other sites: 'For other sites, use webscraping_ai_fields.' It also explains what happens for unsupported URLs (400 error, not charged, message lists support), which tells the agent when the tool will not work.

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, openWorldHint=true, so the safety profile is covered. The description goes beyond that with real behavioral context: the credit surcharge on top of scrape cost, the exact response envelope, the null-when-absent rule, and the flat-string constraint on values. It does not mention rate limits or failure modes when the LLM cannot find a field.

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 and immediately followed by the response contract and the value constraint. The cost disclosure and docs link are placed last. No filler or 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?

There is no output schema, and the description compensates well by specifying the return envelope, key set, and value types. For a 13-parameter tool whose schema is fully described, this is close to complete; the only real gap is routing guidance relative to siblings, which matters because the sibling set contains several closely related extraction tools.

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 and the schema already documents all 13 parameters including proxy, country, and timeout. The description nonetheless adds meaning the schema lacks: that field values are flat strings or null, never nested, and that lists must be requested as one delimited string. That is genuine elaboration on the `fields` parameter's semantics.

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 compound operation: scrape a page, then have an LLM extract named values from the page's own content. That is a clear verb+resource and is distinguishable in spirit from question-answering siblings. It stops short of naming any sibling (e.g., webscraping_ai_question or webscraping_ai_selected), so an agent must infer the boundary itself.

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 useful in-band guidance on how to shape requests (request a list as a single delimited string) and a cost note, but no explicit when-to-use versus the other eight webscraping_ai tools and no stated exclusions. Usage is implied by the 'named values, one value per key' framing rather than spelled out.

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. The description adds almost no behavioral context (no mention of fetch cost, blocking/anti-bot behavior, or failure modes), and the parenthetical 'with JavaScript execution by default' actively contradicts the schema, where js is documented as false by default.

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, front-loaded with the core capability. Slightly wasteful only in that the second sentence is a bare documentation link rather than information the agent can act on.

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 fetch tool with 100% schema coverage and no output schema, the description is barely sufficient: it conveys what comes back at a high level but omits any sibling routing and states a default (JS on) that conflicts with the schema. Functional, but with clear gaps around selection and accurate defaults.

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 enum explanations and defaults, so the schema carries the full parameter burden. The description adds nothing beyond the schema (no syntax or format hints for url, wait_for, or js_script), 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 concrete verb and resource: 'Get the full rendered HTML of a web page.' That is enough to distinguish it in spirit from siblings like webscraping_ai_text or webscraping_ai_fields, but the description never names or contrasts those alternatives, so the differentiation rests on the agent inferring 'HTML' vs 'text' on its own.

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 when-to-use guidance, no exclusions, and no routing to the alternative siblings (text, selected, fields, question, serp) that all fetch from the same site. The only non-purpose sentence is a link to external API docs, which is a pointer rather than 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?

Goes well beyond the annotations by disclosing the exact error contract (body.error starts with 'Invalid page or question'), that credits are refunded on failure, and the specific cost model (5 credits on top of the scrape's normal cost). These are behavioral traits an agent cannot infer from readOnlyHint/openWorldHint alone.

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 what the tool does and its return type, then routing/error/cost details, then the docs link. Every sentence conveys distinct, actionable information with no redundancy.

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

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

Despite 13 parameters and no output schema, the description covers return format ('plain text'), the error shape and refund behavior, cost, and sibling routing. 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 are already documented in the schema; the description adds no per-parameter detail (e.g., js, proxy, or question syntax). Baseline 3 is appropriate when the schema carries the full parameter burden.

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 chain (scrape a page, have an LLM answer a question using only the page's own content) and the return type (plain text). The scope constraint 'using only the page's own content' distinguishes it from tools that read or manipulate the page, letting an agent separate it from siblings without opening schemas.

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 names when to use it ('a single fact or short answer') and names two alternatives with their selecting conditions: webscraping_ai_fields for several named values at once, webscraping_ai_text to read/reason over the whole page yourself. It also states the failure condition that produces an error.

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 safety is covered. The description does add one genuinely useful behavioral fact — only the FIRST matching element is returned, so extra matches are silently ignored — but says nothing about cost, rate limits, or failure behavior for a paid scraping API.

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, front-loaded with the core behavior and with zero redundancy. The trailing docs URL is a reasonable pointer but occupies half the text without adding inline value.

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, mutation-free read tool with a fully documented schema, the description is adequate but minimal. It omits the first-match caveat's practical implication (no error when zero matches), and gives no sense of the response shape or cost, though the scope claim is correct.

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%, with detailed prose on proxy tiers, timeouts, js flags, and enum options, so the schema carries the parameter burden. The description adds no syntax or default information beyond it, which makes the baseline 3 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?

States a specific verb (Get), resource (HTML of the first matching page element), and a precise selection mechanism (CSS selector), which implicitly separates it from the whole-page sibling webscraping_ai_html and the plural webscraping_ai_selected_multiple. It stops short of naming those siblings explicitly, so an agent must infer the routing.

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?

No guidance on when to prefer this over webscraping_ai_html, webscraping_ai_text, or webscraping_ai_selected_multiple, and no mention of prerequisites such as JS rendering being needed. The only pointer is a documentation URL, which is a reference rather than usage 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that all matching elements are returned as HTML; it omits rate limits, auth needs, or behavior when a selector matches nothing.

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, zero waste, with the core action front-loaded and the doc link appended last. Nothing repeats the title or restates schema fields.

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 read-only extraction tool with 13 fully documented params and no output schema, the description covers the essential purpose. It could note return structure or empty-match behavior, but the rich schema and annotations carry most of the burden.

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 proxy, timeout, and js are fully documented in the schema. The description adds no syntax, format, or selector-array semantics beyond that, 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?

States a specific verb+resource: 'Get the HTML of all page elements matching a list of CSS selectors.' The multi-selector scope is clear, but it never distinguishes itself from siblings like webscraping_ai_selected (singular) or webscraping_ai_html, so an agent must infer the split.

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?

No when-to-use guidance and no exclusions. With siblings named webscraping_ai_selected, webscraping_ai_html, and webscraping_ai_text, the description should say when to prefer this over those, but it offers nothing.

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 the safety profile (readOnly, non-destructive, openWorld). The description adds real behavioral context beyond them: 10 results per page, position restarting at 1 on each page, per-search pricing, and the fact that failed searches are not charged. It does not describe rate limits or result freshness.

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 tight sentences: the return shape is front-loaded, then pagination/pricing constraints, then the routing hint. Every clause carries information an agent needs, with no filler or restated 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?

With no output schema, the description takes on the burden of describing the return payload and does so by enumerating the top-level fields and key sub-fields, plus pagination and cost behavior. Nothing needed to call this tool correctly appears to be 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 the baseline is 3, but the description adds semantics the schema does not carry — notably the 10-results-per-page size and the position restart behavior that governs how the 'page' parameter should be used. That is meaningful added value over the schema's bare 'Results page number' text.

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+resource ('Search Google') and names the exact return payload (organic_results with position, title, link, snippet, etc.), which no sibling tool produces. An agent can distinguish it from webscraping_ai_text or webscraping_ai_html without opening any schema.

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 gives explicit usage context — 'Use it to find pages, then read them with webscraping_ai_text or the other tools' — which routes the agent to a specific downstream sibling. It stops short of stating when NOT to use it or which sibling to prefer for a direct-page read, so it is clear but not exhaustive.

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 safety is covered. The description adds useful transformation behavior (boilerplate removal, Markdown structure retention), but says nothing about authentication, rate limits, or how failures surface, which would matter for a network 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 tight sentences plus a docs link. Purpose and output format are front-loaded, and 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?

No output schema exists, but the description compensates by stating the return format (Markdown with structure preserved). With annotations covering safety and the schema covering all 14 params, the definition is nearly complete; only the option to change response format via text_format goes unmentioned in prose.

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 14 parameters (js, proxy, timeout, text_format, etc.) are already documented in the schema, including enum guidance and defaults. The description adds nothing parameter-specific, so baseline 3 is correct.

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') and describes the output shape (boilerplate stripped, structure kept). This implicitly distinguishes it from siblings like webscraping_ai_html or webscraping_ai_data, but it never names those alternatives 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?

'Best for reading a page or passing it to an LLM' implies a use context but gives no when-not-to-use guidance and does not name the sibling tools (question, fields, html, data) that would be the alternatives for other extraction needs.

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