capture_page_screenshot

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

With no annotations, the description carries the full burden and succeeds exceptionally. It discloses that the MCP image is attached even when save_path is set, that width/height are device pixels rather than CSS pixels, that `size` is the byte count, that base64 appears only when return_base64=true, and that the model may not have actually seen the pixels if it cannot consume images. These are exactly the non-obvious behaviors that would cause agent misuse.

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?

Five dense sentences, each earning its place: purpose, return behavior, unit warning, fallback routing, and base64 condition. The core action is front-loaded, and there is zero filler. The length is justified given 9 undocumented parameters and no annotations; every clause prevents a distinct misunderstanding.

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?

Given the complexity (9 optional params, 0% schema coverage, no annotations, no output schema), the description covers the critical operational facts: return shape, save_path semantics, pixel-unit trap, conditional output, and image-consumption fallback. Remaining gaps are minor — it does not clarify how tab_id/session_id select the target when omitted, nor valid format/quality value ranges — but these are largely inferred from names and defaults.

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 0%, so the description must compensate, and it does for the most error-prone parameters: save_path (controls only disk output), return_base64 (the sole switch for base64), format/quality (optional JPEG/WebP), full_page and clip (scoping modes), and the unit semantics of image dimensions. It does not address tab_id, session_id, or timeout behavior, but the critical traps are covered, which justifies a 4.

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 lead sentence states a specific verb and resource: 'Capture a viewport, full-page, or clipped screenshot of a page/tab via CDP'. This distinguishes it from capture_desktop_screenshot (desktop vs page/tab), save_pdf (document vs image output), and scan_page (which is explicitly named as an alternative, not a screenshot tool). The scope, method, and format options are all identifiable without opening the 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?

The description gives explicit when-not-to-use guidance with named alternatives: 'If the current model cannot consume images, it has not seen the pixels and must use scan_page, execute_js, a page-specific API, or OCR instead.' This is a clear exclusion with concrete fallback tools. It does not explicitly contrast capture_desktop_screenshot or state positive selection criteria ('use this when you need page pixels'), though the first sentence implies it, so a 4 rather than a 5.

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