browser_watch_console

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the buffer cap (500 entries), the captured message types (log/info/warn/error/debug + window errors), and that capture is toggle-based. It leaves unstated whether the buffer is cleared or retained on disable, and whether the operation requires any permission — modest gaps for a low-risk toggle.

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?

Two compact sentences, verb-first and front-loaded, with the parenthetical message-type list earning its space by telling the agent exactly what will be captured. No wasted text.

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?

No output schema or annotations exist, so the description must be self-sufficient; it covers the capture behavior, the cap, and the retrieval path. The remaining gaps — disable semantics and the default tab_id — are minor for a simple toggle tool.

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%, so the description must compensate for both parameters. It implies tab scoping ('on a tab') and the enabled/disabled toggle, but never explains that tab_id defaults to null (presumably the active tab) or that enabled defaults to true, so an agent must inspect the schema for defaults. Partial compensation warrants the baseline 3.

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+resource ('Toggle console capture on a tab') and immediately distinguishes itself from the sibling it could be confused with by naming browser_console_logs as the retrieval counterpart. An agent can tell what this does and how it differs from the logs reader without opening either 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?

Clearly frames the workflow: enable capture here, then retrieve via browser_console_logs. It communicates the useful context that buffering only happens while enabled, but stops short of explicit when-not guidance (e.g., what happens if toggled off, or whether it conflicts with browser_capture_network).

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