zerodom_screenshot

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

With no annotations, the description carries the full disclosure burden, and it clearly states the side effect (screenshot saved to disk), the return behavior (path returned), and the default behavior when path is omitted (temp file used). It also specifies the full-page capture scope. It does not mention overwrite behavior or file format, but those are minor for this operation.

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 first sentence is front-loaded and efficiently states the core purpose, behavior, and return. The second paragraph adds useful but somewhat tangential implementation context about report.py and the async/sync split, which may distract an agent; however, it is not redundant and the overall length remains reasonable.

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?

The tool is simple: one optional parameter and an output schema, so the description does not need to explain return structure in detail. It covers the operation, save behavior, path semantics, and default. Minor details like path format or whether an existing file is overwritten are unstated but are not critical for correct invocation.

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 0%, but the description fully compensates for the single parameter: path selects the save location, and omitting it uses a temp file. This adds exactly the practical meaning an agent needs beyond the bare string/null type and default. This is a strong example of description-driven parameter documentation.

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 opens with a specific verb and resource: a full-page screenshot of the active tab, saved to disk, returning the path. This clearly communicates the tool's function and distinguishes it from the many DOM-interaction siblings like zerodom_click_node or zerodom_eval_js. It is not a tautology and includes the outcome and return value.

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 context that this screenshot capability is for the attached async session, contrasting with report.py's separate CLI sync browser. This is an implied when-to-use signal, but the reference to report.py and playwright_wrapper.py is not framed as an actionable alternative-selection rule. It does not explicitly state when to avoid this tool or prefer a specific sibling.

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