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

Annotations already cover the safety profile (readOnly, openWorld, idempotent, non-destructive), and the description still adds a lot on top: per-call pricing with free errors, real JS execution with network-idle waiting, a 2-6s typical / ~25s busy latency range, an 8000px full-page cap, and DNS-based domain refusals. That is exactly the extra behavioral context this dimension rewards.

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?

Information-dense with essentially zero filler, and the operational facts (defaults, timing, output shape, refusals) arrive early. Leading with the $0.008 price is arguably the least useful first token for tool selection, but every sentence otherwise earns its place.

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 return contract itself: JSON containing image_base64 plus finalUrl/status/title, or raw bytes. Combined with latency expectations, size caps, and refusal behavior, an agent has everything needed to call this correctly on the first try.

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 already documents every parameter, its range, and its default; the description largely restates defaults (1280x800 viewport, PNG/JPEG, dark mode, extra wait) and the example.com fallback. It also refers to a 'format=png|jpeg' selector, but the actual parameter is named 'type', a naming mismatch that could mislead an agent. Baseline 3 is appropriate for a fully documented 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 gives a specific verb and resource (render a public page in headless Chrome and return a screenshot) plus the exact output artifacts (PNG/JPEG, viewport or full page). It is trivially distinguishable from siblings like page_metadata, url_to_markdown, and website_audit, which extract text rather than pixels.

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 concrete use cases (visual QA, link previews, archiving, feeding a vision model, checking what a page really shows) and states the refusal boundary (adult/malware domains, private addresses). It never routes the agent to an alternative sibling for text-only needs, so the 'when not to use this' half is missing.

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