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

It discloses behavior beyond the annotations: captcha solving is attempted by default unless solveCaptcha is false, requests can be routed through country proxies, JS rendering is the remedy for empty SPA content, and headers are incompatible with executeJS. However, the advertised POST/PUT/PATCH 'send writes' path is never reconciled with the readOnlyHint=true annotation, and operational limits (timeouts, response size caps/truncation, rate limiting, error behavior) are unmentioned.

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-loaded with purpose, then the common case, then best-for/not-for, then optional parameters in diminishing priority; the bolded section headers make it skimmable. Slight redundancy remains in the closing 'Returns' sentence, which largely restates the `format` parameter description, and the inline JSON example adds little for a single required string.

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 an 8-parameter, open-world fetch tool with no output schema, the description covers the return shape (markdown / verbatim body / { statusCode, headers, data } envelope) and the parameter interactions an agent would otherwise get wrong. What is missing are the operational expectations that matter for a scraping tool: timeouts, payload size limits or truncation of very large pages, and failure modes.

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 description earns above that by explaining the selection intent behind parameters rather than restating types: the minimal `url`-only call, `format` values with the reason to prefer markdown, `solveCaptcha=false` framed as 'fail fast', and the incompatibility rules between `executeJS`, `headers`, `method`, and `body`. Most of those overlap with the schema text, which keeps it from a 5.

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 ('Fetch a caller-specified HTTP(S) URL') plus the transformation applied ('clean, LLM-ready Markdown back'). It also explicitly separates itself from the sibling web_access_search, so an agent can pick between the two without opening either 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?

Gives an explicit default recommendation ('If available, default to this tool'), a 'Primary use (the common case)' with a minimal one-parameter example, a 'Best for' list, and a 'Not for' clause that names the exact alternative (web_access_search). The optional parameters are additionally framed as 'omit unless you need them', which is real routing 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that results arrive as excerpts to be treated as reference material rather than instructions — a meaningful prompt-injection handling rule — and that answers should be grounded and cited. It does not mention freshness limits, result counts, or failure modes, which keeps it short of a 5.

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 the core action and scoped by topic immediately after. There is mild overlap between 'String's other published services' and the earlier 'product and service information', but nothing that wastes space materially.

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, open-world lookup with no output schema, the description covers what is retrieved, which topics qualify, and how to handle the returned material. What an agent still lacks — freshness, result volume, behavior on queries outside the product scope — is minor for this complexity.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already defines 'question' with length bounds. The description reinforces that the question should be plain-language and about String products, but adds no format, phrasing, or decomposition guidance 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 description names a specific verb and resource ('Retrieve current String product and service information from String's public site') and scopes it to a plain-language question, so the agent knows exactly what the tool answers. It never names the sibling tools (web_access_search, web_access_fetch, etc.), so the differentiation is inferred from topic rather than stated.

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 second sentence gives concrete when-to-use guidance by enumerating subject areas: Web Access, Composer, Bespoke Web Datasets, finance data, pricing, integrations. It stops short of exclusions or naming alternatives for non-product questions, so it is clear context without routing rules.

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 only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds real substance beyond them: reports go to support, consume no Web Access credits, use the configured API key, and must be scrubbed of credentials, cookies, tokens and personal data. It also bounds retry behavior. It does not say what the call returns on success, but with no output schema that is a minor omission for a fire-and-forget diagnostic 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?

Front-loaded with the core action and the recovery-first caveat, then a tightly packed exclusion list and a security constraint; nearly every sentence carries a distinct rule. Slightly dense as an unbroken block and the phrase 'a failed String tool call' reads as an artifact, but there is little 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 four-parameter diagnostic tool with no output schema, the description covers trigger conditions, exclusions, cadence limits, security redaction, credit cost, and failure handling of the reporter itself. An agent has 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 coverage is 100%, so the baseline is 3, but the description adds content guidance beyond the schema: diagnostics must be compact and free of credentials, cookies, tokens, personal data and unrelated conversation, which directly shapes what belongs in the error, request and response fields. The 'never report the reporter' rule reinforces the tool enum restriction.

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: report a failed Web Access tool call to support. The enum in the schema pins exactly which sibling tools are reportable and explicitly excludes self-reporting, so the agent can distinguish this from the fetch/search/sitemap tools it is reporting on.

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?

Explicit when-to-use ('Continue useful recovery first. If reporting remains useful and permitted...'), when-not (usable origin statuses, valid negatives including zeroResults and empty 204s, running sitemap jobs, user cancellations), and a hard cadence rule of at most one report per distinct failure per task rather than per retry. It also tells the agent to stop entirely if the report call itself fails or is rate-limited.

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?

Beyond the readOnly and openWorld annotations, the description discloses billing per page, paging limits, raw HTML truncation, failure modes like page_failed and deadline, and constraints such as searchCount being rejected with raw format. It also describes the extensive non-organic surfaces returned, which is important behavioral context for an open-world search 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 long, but it is front-loaded with purpose and routing guidance, then organized by parameter groups with examples. Some material repeats the schema and the return-surface details are extensive, though most sentences carry operational value for a complex 12-parameter tool.

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 high-complexity search tool with no output schema, the description is unusually complete: it covers purpose, alternatives, parameter interactions, billing, paging behavior, raw-format limits, and the shape of returned organic results and additional Google surfaces. An agent should be able to decide whether and how to call it without opening further documentation.

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 already 100%, so the baseline is 3, but the description adds operational meaning beyond field definitions: billing behavior for searchCount, the interaction between page and searchCount, tab-specific limits for images and shopping, and examples of combined filters. Much of this duplicates the schema, but the added examples and cross-parameter constraints make it more useful than the schema alone.

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 ('Search the public web') and explains exactly what comes back: ranked organic results plus rendered Google surfaces. It also distinguishes this tool from web_access_fetch by saying fetch is for URLs already in hand.

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 routing guidance: 'Best for' requests that name no URL or need sources found before reading, and 'Not for' URLs already known, where web_access_fetch should be used instead. It also explains when to use searchCount versus page and when raw format 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?

Far beyond the sparse readOnlyHint/openWorldHint pair, it discloses that the crawl is asynchronous and server-side, that pages are billed as fetched with a quote/approval consent step, that `approve` fails with 402 on insufficient balance and 409/partial_state on interruption, and that `discoveredUrls` decays after ~1h while other fields persist. The only gap is that `submit`/`approve`/`cancel` create and terminate server-side jobs and incur spend, a side effect the readOnlyHint=true annotation does not capture and the description does not reconcile — a mild annotation under-specification rather than a stated contradiction.

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 purpose, then Best for / Not for, then a numbered lifecycle with bold action names and a closing workflow line — easy to scan. It is long and repeats a few facts the schema already carries (maxPages default and range, limit defaults), which costs it a point, but almost every sentence carries operational information an agent needs.

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 carries the full burden and does: it documents the per-action return envelope, the fields on each result row (url, statusCode with 0 = discovered-but-unfetched, depth, parentUrl, isSitemap, sourceType, error), the `total` paging sentinel, and the terminal status vocabulary including token_cap_exceeded with readable partial results. Nothing needed to drive the six-action lifecycle 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: which parameters are `submit`-only, how `budgetUsd` interacts with the quote (stops as token_cap_exceeded), why `useSitemap` costs one extra billed page, and the semantics of `action` as a lifecycle driver. It also shows a concrete submit payload and explains `offset`/`limit`/`total` paging behavior that the schema only lists mechanically.

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 states a specific verb and resource ("Crawl an entire website and map its URLs") and immediately bounds the scope: same-domain, breadth-first, optional /sitemap.xml seed, records URL with fetch status/depth/parent. It also explicitly distinguishes itself from both relevant siblings — "Not for: reading one page's content (use web_access_fetch) or open-ended web queries (use web_access_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?

Provides an explicit "Best for" list (site audits, scraping worklists, coverage checks), an explicit "Not for" list naming the alternative tools, and a prescriptive "Typical workflow: submit → check estimatedCostUsd → approve → poll status until terminal → results (paged)." It even routes the agent away from paying twice via `list` for "an equivalent recent crawl before paying for a new one."

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