browser_screenshot

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's read-only nature is confirmed. It adds useful details like default marks behavior and the security warning about untrusted text. Lacks some parameter effects, but the 'where supported' caveat provides context. Slight gap in not explaining what happens when marks is false, but overall satisfies the standard.

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?

The description is a single paragraph but efficiently covers purpose, usage, and security. It front-loads the core action and then adds use-case conditions and a practical tip. The security note is a minor add-on. Could be slightly improved with bullet points for scannability, but overall it is well-structured and compact.

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 screenshot tool, the description covers the core functionality, usage scenarios, and integration with siblings. It lacks details on output format specifics (dimensions) and parameter effects, but the annotations and purpose cover the essentials. Given the tool's simplicity and existing annotations, it is nearly complete.

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 coverage is 50%, meaning marks and tabId are partially described in the schema. The description adds meaning by explaining marks as 'label controls with their refs' and clarifies that the image can be used for click_xy, but tabId is not elaborated beyond the schema. Given moderate coverage, the description does not fully compensate but is adequate.

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 clearly states it takes a screenshot of the visible viewport, with format details (JPEG, CSS pixels) and a specific purpose. It distinguishes itself from siblings like browser_observe by focusing on visual capture when the element table is insufficient.

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?

Provides explicit guidance on when to use (canvas-rendered apps, charts, visual state) and when not to (element table sufficient). Also describes how to use the output with browser_act for clicking coordinates, which is crucial for tool chaining.

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