webview

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

The annotations already declare destructiveHint=true, openWorldHint=false and readOnlyHint=false, so the safety profile is partly covered. The description adds genuine behavioral context the annotations cannot: the WebView must already be debug-enabled and it will not force-enable it, and network events are only captured after Network is enabled. However, it never explains what the destructiveHint actually entails, what state close resets, or what happens to the target if it is not already debuggable.

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?

Three short sentences, front-loaded with the target resource and the workflow order, with no filler. The compression is close to hurting comprehension ('discover/open后scripts/source/dom/network/body' is a bare token list), which keeps it from a 5.

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 a 9-parameter, destructive, multi-action tool with no output schema, the description covers the lifecycle and the key prerequisite but leaves a lot open: no indication of what scripts/source/dom/network/body return, no per-action parameter requirements, and no note on whether close is mandatory to release the debug target.

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%, so the description must carry the parameter burden and it only partially does: it names serial, packageName and pid and its action list mirrors the action enum. Five parameters (targetId, scriptId, requestId, sessionId, rootRead) are left completely unexplained, and the description never says which identifiers are required for which 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 the concrete resource (an already-opened, debug-enabled WebView) and the identifying keys (serial/packageName/pid), then enumerates the action pipeline discover/open → scripts/source/dom/network/body → close. That is a specific verb+resource statement, though the telegraphic phrasing ('明确...的已开放调试WebView') is denser than it needs to be. It does not explicitly differentiate itself from siblings such as frida or device, so it stops short of 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?

It gives a clear in-tool usage order (discover/open first, then the collection actions, close last) and states two boundaries: no external URLs and no forced enabling of debugging. What is missing is any comparison against alternative tools in the catalog for inspecting app internals, so the agent gets strong guidance but no alternatives.

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