screenshot

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot express: default downscaling to 1024px, JPEG quality-55 encoding, and that annotate=True overlays snapshot refs (e12). It does not, however, say what is returned (an image payload vs a reference), whether output is inline or a URL, or how large captures behave — meaningful gaps for a tool whose whole output is a binary asset.

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 the cost warning and the alternative routing before any parameter detail. No filler, and the parenthetical parameter notes are compact rather than repetitive.

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 capture tool with no output schema and six undocumented parameters, the description covers the decision-relevant surface: why to use it, default sizing/encoding, and annotation. It falls short only on full_page semantics and on whether the result is inline image data or a file reference.

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?

With 0% schema description coverage the description must carry all parameter meaning, and it documents four of six well: max_width (1024 default, 0 = full size), format ('png' for lossless), quality (1-100), and annotate (draws refs). selector is only implied by 'one element' and full_page is never mentioned, leaving two parameters to guesswork.

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 first sentence names the exact resource and scope: a screenshot of the page or a single element. It immediately distinguishes itself from extractive siblings (snapshot, get_markdown, find_in_page), so an agent knows this is the visual-capture tool and not the content-reading one.

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 an explicit cost-based selection rule — images are expensive, prefer snapshot/get_markdown/find_in_page, use this only when layout matters — naming three concrete alternatives and the condition that selects each. That is about as decisive as when-to-use guidance gets.

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