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 adds genuinely non-obvious behavior beyond that: the JSON-to-rendered-HTML fallback when no structured data exists, and the billing consequence of that fallback. It does not mention authentication, rate limits, or latency for the external ScrapeUnblocker 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 sentences, front-loaded with the core action and output type, then the edge-case fallback. Every clause earns its place: the doc link, the output examples, the no-structure case, and the billing note each add 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?

With no output schema, the description must convey the return shape, and it does: parsed structured JSON with named categories, or the rendered HTML plus an explicit signal when no structured data is found. For a two-parameter read-only tool this is close to sufficient; only external API auth/limits are unaddressed, and those are arguably outside the tool contract.

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 both url and proxy_country documented in-schema, so the schema carries the parameter burden. The description adds only indirect meaning about what the url will yield (product/article/listing parsing); it says nothing about proxy_country or geo-affinity for the parse. 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 (fetch a web page) plus the distinguishing output: AI-parsed structured JSON rather than raw HTML, with concrete examples of the structured categories (product details, article content, listings). The contrast with 'instead of raw HTML' and the reference to billing 'like fetch_html' makes it separable from the fetch_html/fetch_markdown siblings 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?

Usage context is clear: pick this when you want parsed structured data, and the description warns that pages without structured data fall back to rendered HTML billed like fetch_html, which implicitly signals when the raw-HTML siblings would have been equivalent. There is no explicit 'use fetch_html instead when...' routing statement, so it stops short of full when-not guidance.

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