Evaluate JS in Webview

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

Annotations include destructiveHint: true, indicating potential destructive effects. The description does not explain what might be destructive, leaving the agent uncertain. It does provide useful technical details like using returnByValue and awaitPromise, and warns about JS syntax limitations on old devices, which adds value. No contradiction with annotations, but could better clarify side effects.

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 concise and information-dense, with no fluff. It front-loads the main action and technical details, then adds a critical compatibility warning at the end. Every word 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?

Given no output schema, the description mentions it returns JSON, which is helpful. However, it does not specify the exact structure of the return value (e.g., whether it includes exceptions, result object). It also lacks behavioral details about side effects, which is important due to destructiveHint. The description is adequate but not complete.

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?

The schema description coverage is 100%, so parameters are already documented. The description adds an example of expression format and the meaning of device serial, but the schema already provides that. Minimal added value beyond schema.

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 clearly states the tool evaluates JavaScript in a webview and returns JSON results, specifying the protocol method and options. It mentions execution context and return behavior. It does not explicitly differentiate from sibling tools like webview_click_text or webview_get_computed_style, but the focus on arbitrary JS evaluation is distinct enough.

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 description implies usage for running JavaScript in a webview but does not state when to prefer this over alternatives, such as using dedicated tools for clicking or styling. It also does not mention prerequisites like needing a webview connection (via webview_connect). The warning about old devices is a usage constraint but not for alternative selection.

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