browser_snapshot

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

No annotations exist, so the description carries the full burden. It does disclose the two return components (ARIA tree and index list) and the downstream linkage to browser_click, which is valuable. But it omits whether browser_id defaults to a specific browser, whether the snapshot reflects the current page state, and gives no warning that ARIA snapshots can be very large.

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?

One sentence, front-loaded with the primary return value, with the actionable linkage to browser_click packed into a short parenthetical. Nothing is wasted or buried.

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?

With no output schema and no annotations, the description has to do more work than it does. It covers what comes back and how to use the result, but leaves the optional/required nature of browser_id and the expected size of the ARIA payload unexplained.

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?

There is one parameter (browser_id) with 0% schema description coverage, and the description never mentions it or explains its role. With a single undocumented parameter and no description compensation, the agent must guess how to target a browser. The stated 'feed browser_click' hint applies to output indexes, not to this input.

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 specific verb and resource: return the page's ARIA accessibility snapshot plus a clickable element index list. That clearly distinguishes it from browser_screenshot (visual capture) and browser_read (text extraction). Sibling differentiation is only indirect, achieved through the parenthetical naming browser_click.

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 parenthetical '(indexes feed browser_click)' implies the intended workflow of snapshotting before clicking, which is genuinely useful guidance. However, it never states when to prefer this over browser_screenshot, browser_read, or browser_evaluate, and gives no exclusions.

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