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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the 1-credit cost model (per successful request regardless of format count), differentiated latency (~5-15s for Chromium screenshot vs ~1-5s for other formats), and that screenshots arrive as an image attachment. These are exactly the operational traits an agent needs to plan around.

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, each earning its place: capability, cost, latency, use cases. The capability and payload are front-loaded, and there is no restatement of the tool name or 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 5-parameter, no-output-schema tool with read-only annotations, the description covers capability, cost, timing and payload form well. It stops short of mentioning error/edge behavior (non-2xx pages, blocked or JS-only sites, timeout semantics) that an agent invoking against arbitrary URLs would benefit from.

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, but the description adds real semantics on top: it explains that cost is flat regardless of how many formats you request, and that choosing the screenshot format carries a disproportionate time cost. That trade-off context is not derivable from the enum list 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?

States a specific verb and resource (scrape any web page) and enumerates the exact outputs — Markdown, rendered/raw HTML, links, SEO metadata, screenshot — so the agent knows precisely what it gets back. This is clearly distinguishable from siblings like google_serp or get_social_post, which return search/social data rather than raw page content.

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 gives concrete use cases (reading article content, extracting metadata, link discovery, visual captures), which tells the agent when this tool is appropriate. It does not, however, name an alternative tool or state when NOT to use it (e.g. prefer google_serp for query-style discovery), so the routing guidance 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.