Capture Webview Network

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

The annotation readOnlyHint=true already covers the safety profile, so the description only needs to add non-obvious behavior. It adds that the capture runs for N milliseconds and collects specific fields, which is useful. However, it does not disclose whether the call blocks for the full duration, whether it returns immediately, or whether it affects ongoing network monitoring; it also omits the return format.

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 description is a single compact sentence with zero filler. It front-loads the core action and scope, immediately followed by the relevant captured fields. Every element earns its place.

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 (2 params, 1 required) and the read-only annotation covers safety. Yet there is no output schema, and the description does not describe the return structure, so an agent must guess at the response format. It also omits any mention of requiring an active webview connection, which is relevant context given the sibling webview_connect/disconnect tools.

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 100%: both 'ms' (duration, default 3000) and 'device' (target serial) are already documented in the input schema. The description merely restates the 'N milliseconds' concept and adds no new meaning beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb ('抓'/'capture') and a clear resource ('webview 的网络请求'/'webview network requests'), scoped by a duration (N milliseconds). It also enumerates the captured fields (url/method/status/type) and explicitly ties it to the Network domain, making it distinct from every sibling webview tool (screenshot, evaluate, DOM outline, etc.).

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 implied by the tool's unique purpose: there is no other network-capture sibling, so an agent can infer when to call it. However, the description does not explicitly state prerequisites (e.g., whether a webview connection via webview_connect is required) or mention any exclusions/alternatives, leaving the when-to-use guidance implicit rather than explicit.

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