webview_control

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the transport (exposed DevTools sockets), the hard scope limit (debuggable WebViews only), and a dependency caveat for the mutating/executing actions. It does not state that click/fill mutate page state, what happens on timeout, or what a socket/page_id refers to, leaving meaningful gaps for a 9-parameter tool.

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 dense, front-loaded sentences with no filler; the operation list and the two hard constraints come immediately. The slash-separated action enumeration is terse to the point of being cryptic, which slightly undercuts readability.

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?

An output schema exists, so return values need not be explained. Given the tool's complexity (9 params, multi-action dispatch, no annotations, 0% schema coverage), the description covers the important preconditions but omits how parameters combine per action, which is the main thing an agent still needs.

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% across 9 parameters, so the description must compensate and largely does not. The action list hints at what the 'action' parameter accepts and implies that css/value/expression pair with click/fill/evaluate, but socket, page_id, timeout, and max_nodes are never explained and no parameter is mapped explicitly to its action.

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 names a concrete verb+resource (WebView/Chrome control over exposed DevTools sockets) and enumerates the supported operations: discover/pages/dom/click/fill/evaluate/navigate/close. It also implicitly distinguishes itself from pixel-based UI siblings by stating 'Uses DOM/CSS instead of pixel clicks' and 'only debuggable WebViews'. It stops short of naming a specific sibling alternative, so it is not a 5.

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?

There is real usage scoping: only debuggable WebViews are supported, and evaluate/click/fill need the optional websocket-client dependency. However, there is no explicit guidance on when to prefer this over the many sibling UI tools (tap_element, element_action, act, get_ui_tree) that operate on native views, nor any when-not conditions beyond the debuggable-WebView limit.

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