web_screenshot

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

With no annotations, the description carries the full burden and does so: it discloses session/login-state reuse, automatic parent-directory creation, a derived default filename under DATA_DIR/screenshots/, non-fatal selector misses, action-chain failures that only write notes rather than aborting, a total deadline budget, and proxy-pool allocation. These are exactly the operational traits an agent needs before calling.

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?

Front-loaded with the one-line purpose and return value before the Args block, so an agent can stop reading early. The Args list is long but each entry earns its place with a default or behavioral note; the only minor cost is a docstring-style layout that is denser than prose would need to be.

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 an 11-parameter browser-automation tool with no annotations, the description covers invocation semantics, failure tolerance, and session prerequisites, and an output schema exists so return-value shape need not be re-explained (the path return is stated anyway). Nothing an agent needs to call this correctly appears missing.

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% and there are 11 parameters, so the description must compensate entirely — and it does, documenting every parameter with defaults and semantics (full_page vs viewport-only, wait_ms for animation/lazy-load, selector as a soft wait, the ordered action chain with click/type/press/select/wait/scroll, deadline_ms budget, proxy fallback order). This adds substantial meaning beyond bare typed fields.

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?

States a concrete verb+resource: render a page with a real browser and screenshot it to PNG, returning the local file path. It also relates itself to siblings by noting it shares the browser pool and login state with web_fetch and depends on the session name used with login. It stops short of an explicit contrast (e.g. 'use web_fetch when you only need text'), so sibling differentiation is implied rather than stated.

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?

Usage is conveyed indirectly through '适合"给模型看一眼页面长什么样"' and the note that login/JS-rendered pages need a saved session matching the login session name. There is no explicit when-to-use-this-vs-web_fetch/web_extract guidance or when-not condition, leaving the agent to infer the choice from the framing.

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