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

With no annotations, the description carries the transparency burden. It discloses a key side effect: '触发浏览器历史导航，可能重新加载页面' (triggers browser history navigation, may reload the page). This adds useful behavioral context beyond a bare 'go back', though it doesn't detail failure modes or prerequisites.

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 two sentences, front-loaded with the primary purpose, followed by a concise side-effect note. Every word earns its place; no filler or redundancy.

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 description is sufficient for a simple navigation tool with no output schema: it states the action, scope (active tab), and a relevant side effect. It does not mention behavior when there is no history, but this is a minor gap given the tool's simplicity and the schema coverage of parameters.

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 input schema covers 100% of parameters with detailed descriptions (timeout, wait_until). The tool description does not add parameter-specific meaning, but the schema already provides sufficient semantics, so the baseline score 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 clearly states the action: '在活动标签页中后退到上一页历史记录' (go back to the previous page in history in the active tab). It uses a specific verb and resource, and inherently distinguishes from siblings like web_forward and web_refresh.

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 (when you want to navigate back) but does not explicitly mention when to use vs alternatives like web_forward or web_refresh. No exclusion criteria are provided, so it remains at the 'implied usage' level.

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

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

No annotations are provided, so the description carries full burden. It discloses that dispatching mouse events may trigger navigation, form submission, or script side effects, and notes dependency on the most recent web_snapshot output for ref numbers. This is valuable behavioral context beyond a simple action definition.

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 concise sentences with clear front-loading: purpose, target/capabilities, and a safety warning. Every sentence adds distinct value and no redundancy is present.

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 annotations and no output schema, the description covers purpose, target selection, capabilities, and side effects. A minor gap is that the schema marks no required parameters, and the description does not explicitly state that at least one of ref/selector must be supplied, though '二选一' in the schema implies it.

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?

Input schema covers 100% of parameters with detailed descriptions, including mutual exclusivity between ref and selector. The description only adds a minor recommendation that snapshot ref is preferred, so it mostly restates schema information without significant new meaning.

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?

Description clearly states '点击页面元素' (click page elements), enumerates target modes (snapshot ref or selector), and supports mouse buttons, double-click, and modifier keys. This distinguishes it from sibling tools like web_hover, web_press, and web_type.

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 gives guidance on how to specify targets (prefer snapshot ref, otherwise selector) but does not explicitly contrast with alternatives like web_hover or web_press. When-to-use vs not-use is only implied by the action name, not stated.

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

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

无注解，描述承担全部行为披露责任。完整说明返回值序列化规则（undefined→null、循环引用→[Circular]、NaN/Infinity→字符串、超长截断）、语句序列中函数声明不返回结果的特殊行为，以及高危权限（可读 cookie、登录态、发起网络请求）。

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?

描述虽然较长，但每一句都承载必要信息：形态区分、返回值处理、异步建议、安全警告。结构清晰，先功能后细节，无冗余或重复内容。

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?

对于执行任意 JS 的高复杂工具，描述覆盖了输入形式、返回值转换、异步处理、权限风险等关键方面。虽无输出 schema，但返回值行为的说明已足够Agent判断预期结果。

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 已覆盖两个参数且描述完整，但工具描述进一步补充了 arg 仅用于函数形态并作为参数传递，以及 script 可接受函数/表达式/语句序列三种形式，赋予参数更丰富的语义，超越 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?

明确说明“在页面上下文中执行 JavaScript 并返回结果”，动词+资源+作用域清晰，与所有兄弟工具（如点击、填写、滚动）形成明确区分，不存在歧义。

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?

详细说明三种脚本形态（函数表达式、表达式、语句序列）及各自适用场景，并提示异步逻辑应使用 async 函数。虽未显式对比替代工具，但兄弟工具皆为页面交互操作，隐含了本工具的独特用途；安全警告也给出了使用前提。

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool clears existing content before filling, triggers input and change events, and may cause validation or submission logic. This is strong transparency for a mutation tool, though it doesn't discuss failure modes or edge cases.

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 well-structured. It front-loads the core action ('Clear and fill'), then specifies targeting and events, and ends with a permission note. Every sentence earns its place with no redundancy.

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 description is complete for a simple fill tool: it covers purpose, targeting, clearing behavior, event triggering, and potential side effects. The schema documents parameters (including timeout). The lack of an output schema and annotations is offset by the explicit behavioral notes. Minor gaps include error handling and return value behavior, but these are not critical for this 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?

The schema covers 100% of parameters with descriptions, so the baseline is 3. The prose description adds little beyond the schema, as it merely restates the ref/selector targeting and the clearing behavior already documented in the value parameter. No additional semantic value is provided.

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's function: clear and fill input fields, textareas, or editable regions. It also specifies the targeting mechanism (snapshot ref or selector) and post-fill events. However, it does not explicitly differentiate from sibling tools like web_type, which is a minor gap.

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 filling form fields and indicates that targeting is via snapshot reference or selector. It does not provide explicit guidance on when to prefer this over web_type or web_select, nor does it mention exclusions. The context is sufficient for basic use but lacks comparative direction.

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

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

With no annotations, the description must carry the transparency burden. It discloses that it '触发浏览器历史导航，可能重新加载页面' (triggers browser history navigation, may reload the page), which is useful side-effect information. However, it omits other relevant behaviors like what happens when there is no forward history, or whether the tool waits for navigation completion. Some transparency is provided but not comprehensive.

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 succinctly written in two sentences, front-loading the core purpose immediately. The permission note is on a separate line for clarity. Every sentence adds value without redundancy, making it highly concise and well-structured.

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 simple navigation tool, the description covers the main action and a key side-effect. However, with no output schema, it does not specify what the tool returns or how failures (e.g., no forward history) are handled. The absence of this information leaves moderate gaps for an agent attempting to use the tool effectively.

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 input schema has 100% coverage with detailed descriptions for both timeout and wait_until, including explanations of each enum value. The description adds no additional parameter context beyond what the schema already provides. Since the schema already does the heavy lifting, the baseline score 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 clearly states the action: '在活动标签页中前进到下一页历史记录' (go forward to the next page history in the active tab). It uses a specific verb and resource, and naturally distinguishes from siblings like web_back (which goes backward). The title '前进' (forward) reinforces this but the description is explicit.

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 does not provide guidance on when to use this tool versus alternatives such as web_back or web_refresh. It simply describes what the tool does without mentioning exclusions, prerequisites, or alternative tools. No 'use this when...' or 'instead of...' is present.

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

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

With no annotations, the description carries the full burden. It discloses that the tool '派发鼠标移动事件' (dispatches mouse movement events) and '可能触发 CSS 悬停效果' (may trigger CSS hover effects), which reveals the synthetic nature of the action and its potential to cause side effects. This goes beyond a simple 'move mouse' statement, though it omits any error or timeout behavior.

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 two short sentences, front-loaded with the primary action and then a behavioral note. Every sentence serves a purpose without unnecessary filler, making it extremely concise and well-structured.

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 relatively simple hover tool, the description covers the core action, common use case, and a key behavioral nuance. The schema fully documents parameters, and while there is no output schema or annotation, the description provides sufficient context for an agent to understand the tool's purpose and side effects. Minor gaps remain, such as explicit success/error behavior, but these are not critical for a basic hover operation.

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 input schema already provides detailed descriptions for all three parameters (ref, timeout, selector) with mutual exclusivity and default values. The tool description adds no additional parameter meaning, so it meets the baseline of 3 as the schema does the heavy lifting.

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+resource structure ('把鼠标移动到元素上方') and clearly distinguishes itself from siblings like web_click by stating its common use case ('常用于触发悬停菜单与提示'). The action is unambiguous and differentiates well from click, type, and scroll tools.

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?

Provides clear context for when to use ('常用于触发悬停菜单与提示'), implying the tool is for hover-triggered UI interactions. However, it does not explicitly mention when not to use or name alternative tools, so it lacks explicit exclusions.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It mentions that real network requests are made, the page is rendered, and the target site must allow automation. It also explains the active-tab behavior and auto-new-tab fallback, providing meaningful context beyond the schema.

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 two concise sentences: the first states the core action and tab behavior, the second explains wait strategy usage and the permission caveat. It is front-loaded with the primary purpose and contains no fluff or redundancy.

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 tool with only three parameters and no output schema, the description fully covers the essential context: what it does, how it behaves, and a critical permission note. It is complete enough for an agent to select and invoke the tool correctly without additional information.

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 input schema has 100% coverage, so the baseline is 3. The description adds value by linking wait_until to concrete scenarios (single-page app rendering, network completion), which enriches the schema's enum definitions without merely repeating them.

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 navigates the active tab to a specified URL, auto-creating a new tab if none exists. This distinguishes it from sibling navigation tools like web_back, web_forward, and web_refresh, which operate on history or reload rather than arbitrary URL entry.

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 explicitly notes the use of wait_until strategies for scenarios like SPA rendering or waiting for all network requests to finish, giving clear context for when this tool is appropriate. However, it does not explicitly name alternative tools to exclude, stopping short of the highest bar.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool sends keyboard events to the current page and explains the fallback behavior for the focused element. However, it does not mention potential side effects (e.g., navigation triggered by certain keys), how the tool handles page state, or what happens if the key press fails, leaving transparency gaps.

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 two concise sentences, front-loaded with the primary purpose and followed by usage guidance and a permission note. Every sentence earns its place with no redundant or filler content.

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 relatively simple with four parameters, one required, and no output schema. The description covers the core usage and permission scope, but it omits details about return values or how success is signaled, and it does not explain how the timeout parameter affects behavior beyond the schema. Given the lack of an output schema, a bit more context on expected outcomes would improve completeness.

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%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining that ref/selector can be used to focus the target element and that omitting them results in acting on the currently focused element. This clarifies the intended usage of the parameters and adds a crucial behavioral detail not fully captured by the schemas alone.

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's function: pressing keyboard keys (e.g., Enter, Escape, Control+a). It specifies the resource (keyboard) and provides concrete examples, making the purpose obvious. It lacks explicit differentiation from sibling tools like web_type, but the key-based action is distinct enough to avoid major confusion.

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 provides guidance on how to use the tool: it can first focus a target element via ref/selector, and if not provided, it operates on the currently focused element. This gives clear usage context, but it does not explicitly state when to prefer this tool over alternatives (e.g., web_type) or when not to use it, leaving the decision implicit.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool re-requests all resources of the current page, which is useful, but it does not mention potential side effects like form resubmission or whether it cancels pending tasks.

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 two short sentences, both purposeful. It is front-loaded with the core action and adds a concise permission note without unnecessary fluff.

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 simple refresh tool, the description with full schema coverage is mostly complete. It lacks a few details such as potential side effects or behavior on pages with unsaved forms, but overall it is adequate for the tool's simplicity.

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 input schema fully describes both parameters (timeout, wait_until) with clear descriptions and enums. The tool description adds no extra parameter context, but this is acceptable given high schema coverage.

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 action (reload) and resource (active tab). It is specific and distinguishable from sibling navigation tools like web_back or web_open, though it does not explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives or what conditions make it appropriate. The permission note only explains behavior, not usage context.

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

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

在无注释的情况下，描述补充了'只改变渲染视口，不产生网络请求'，明确该操作无网络副作用，为代理提供了关键的安全信息。对于简单操作，这一披露已足够，但未提及如是否影响滚动位置等细节，故非满分。

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?

描述两句话完成，第一句点明功能，第二句补充安全性，没有任何冗余词汇，也未重复schema中已有的最小/最大值，结构清晰且高效。

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?

该工具仅含2个必要参数且无输出schema，描述已涵盖功能、单位及安全副作用，足以支持代理完成调用。但未提及操作后的页面状态（如重绘或保持滚动位置），因此不构成满分。

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已描述width/height及数值范围，但未说明单位；描述补充了'CSS 像素'，为参数提供关键语义信息，帮助代理正确理解数值基准（区别于设备像素），显著提升参数使用的准确性。

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?

描述直接以'调整浏览器视口尺寸'明确了动作和对象，并限定'CSS 像素'，与兄弟工具（如web_scroll、web_screenshot）功能区分明显，不存在歧义。

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?

描述未说明何时使用或与替代工具的取舍，也未提及适合的场景（如响应式测试）或排除条件。仅能根据工具名称和功能推断用途，缺乏主动的使用指导。

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

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

With no annotations, the description carries the burden and does well: it discloses read-only page content, optional file system write, and return as MCP image. It could add more about prerequisites (e.g., page must be open) but overall transparent.

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?

Description is concise and well-structured: first sentence states function, second gives usage guidance, third covers permissions. Every sentence earns its place with no redundancy.

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 6-parameter tool with no output schema, the description covers core function, return format, side effects, and usage context. It lacks some edge details (e.g., timeout behavior, selector matching), but schema covers those, making it sufficiently 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?

Schema coverage is 100%, so baseline is 3. The description adds context that full_page/selector control viewport vs element and save_to writes locally, but does not add much beyond schema descriptions already provided.

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 captures an image of the current page (viewport or full page) or a specified element, returning it as MCP image content. It explicitly distinguishes from web_snapshot, making the purpose unambiguous.

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 explicitly says it is suitable for visual confirmation and advises using web_snapshot for routine structured observation, providing direct when-to-use and alternative guidance. It also notes the file-writing side effect when save_to is provided.

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

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

The description adds a permission note stating it only changes scroll position and generates no network requests, which is valuable beyond what annotations would provide. It also explains the into_view centering behavior and element-scroll logic. It does not cover error handling or edge cases, but overall it gives meaningful behavioral context.

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, with two sentences covering behavior and permissions. No redundant information or filler, and it is front-loaded with the main purpose.

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 the tool's moderate complexity and lack of output schema, the description covers core behavior and permission context. It does not mention what happens if the selector is not found or if scrolling is impossible, but the essential information for successful invocation is present.

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 descriptions cover all parameters, but the description adds crucial interaction context: how selector, direction, and into_view relate. This goes beyond simple parameter listings and helps the agent understand combined usage.

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 it scrolls a page or element, with specific behaviors for 'into_view' and selector usage. It distinguishes itself from sibling interaction tools by describing its precise scope and behavior.

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 when to use the tool (scrolling) and explains behavior variations based on selector/direction, but it does not explicitly mention alternatives or exclusions. Context is clear, so no exclusions are needed.

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

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

No annotations are provided, so the description must disclose side effects. It does state that the tool modifies page form data, which is an important behavioral trait. However, it does not elaborate on other behaviors such as waiting for element availability, handling of multi-select, or failure conditions, leaving the transparency incomplete.

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, consisting of two sentences that front-load the main function and follow with a permission note. Every sentence contributes purpose, with no redundancy or filler.

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 relatively simple tool with 100% schema coverage, the description covers the core action and side effect. It does not describe return values or more complex interaction patterns, but given the schema richness, it is adequately complete for an agent to select the tool correctly.

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 input schema provides 100% parameter coverage, so the description need not add detailed parameter semantics. The description mentions the choice between value and label, which duplicates schema information but adds no further clarity beyond what the schema already documents.

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 selects one or more options in a drop-down list (select), either by value or by visible label. This specific verb+resource structure distinguishes it from sibling tools like web_click and web_fill.

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 implicitly establishes when to use this tool—whenever interaction with a select element is needed—but it does not explicitly name alternatives or exclusion scenarios. Clear context for dropdown interaction is provided, though no 'when not to use' guidance is given.

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

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

No annotations are provided, so the description carries the full burden. It discloses the shutdown behavior, cleanup of tabs/references, automatic restart on future operations, and loss of unsaved login state. This goes beyond the bare action and provides important operational context for an agent considering this destructive-looking operation.

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 two short, clear paragraphs. The first sentence immediately states the action and scope, followed by restart behavior. The second paragraph covers the permission warning about session state. Every sentence adds value and there is no redundancy.

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 simple 0-parameter tool with no output schema, the description is complete: it explains what happens, the side effects, the auto-restart behavior, and the use case. An agent has all the information needed to decide when to call it and what to expect.

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 tool has zero parameters and the schema has no properties, so description coverage is trivially 100%. With no parameters to document, the baseline is 4; the description appropriately does not discuss any parameters.

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?

Description uses a specific verb and resource: '关闭浏览器实例并清理全部标签页与引用' (close browser instance and clean up all tabs and references), which clearly distinguishes it from sibling tools like tab_close that only close individual tabs. It also states the intended use case of releasing resources or clearing session traces.

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 explicitly states when to use the tool: '用于释放系统资源或清除会话痕迹' (used to release system resources or clear session traces). It also warns about side effects (unsaved state lost) and that subsequent operations will auto-restart, giving the agent context for deciding if this is appropriate. It does not explicitly name alternatives like tab_close, but the scope is clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states it is a read-only operation, makes no network requests, and that the snapshot content is only returned to the caller. It also clarifies the output is structured data and not pixels, providing critical safety and expectation context.

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 well-structured, with the main function front-loaded in the first sentence, followed by usage context, content clarification, and permission note. Every sentence adds essential value without unnecessary filler.

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 there is no output schema, the description explains the return content (title, URL, element tree with refs) and how refs are used. It covers permission and content type. It could mention truncation behavior from max_nodes/max_depth or error cases, but the schema already covers limits, making this sufficiently 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 input schema already provides 100% coverage with descriptions for all three optional parameters (selector, max_depth, max_nodes). The tool description does not add any additional parameter-specific meaning, so it stays at the baseline without enhancing beyond the 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 it generates an accessibility tree snapshot of the current page with title, URL, and element tree with refs. It distinguishes itself from siblings like web_screenshot by explicitly noting it contains structured information, not pixel images, and from web_status by focusing on interactive element positioning.

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 provides clear context by stating that the refs can be used by subsequent web_click / web_fill tools, implying when to use it. It also contrasts with pixel images, separating it from screenshot usage, though it does not explicitly list when not to use it or name alternative tools.

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

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

With no annotations provided, the description explicitly states '只读操作' (read-only operation), disclosing the tool's side-effect profile. It also describes the exact informational content. While it doesn't address edge cases (e.g., behavior when no browser session exists), the read-only disclosure is valuable and accurate.

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 extremely concise: two short sentences. The first sentence front-loads the purpose and deliverables; the second adds the read-only permission note. Every word earns its place, and there is no filler or redundancy.

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 simple, parameterless status tool with no output schema, the description covers the essential elements: running status, tab list (with URL/title), and active tab. It does not specify the response structure, but the enumerated items give a clear expectation. This is nearly complete for a tool of this complexity.

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 tool has zero parameters, and the schema description coverage is effectively 100% (vacuous). Per the rubric, a baseline of 4 is appropriate when no parameters exist, and the description adds no conflicting or redundant parameter information.

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 the specific verb '报告' (report) and clearly identifies the resource ('browser session status'), then enumerates exactly what is included: running state, tab list with URLs and titles, and active tab. This distinctively differentiates it from siblings like web_tab_list, which likely focuses only on tabs.

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 clearly implies when to use this tool: when you need an overall status snapshot including running state, tabs, and active tab. It does not explicitly mention alternatives or exclusions, but the contextual clarity is strong enough that an agent would know when to invoke it.

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

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

With no annotations provided, the description carries the burden and does well: it discloses two key behaviors—defaulting to the current tab and auto-switching to the first remaining tab after closing. It also warns that unsaved form data will be lost, which is valuable for a destructive action.

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 very concise, with two sentences, and front-loaded with the core function. The default behavior and the post-close switching action are stated efficiently, and the permission note adds important context without verbosity.

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 simple one-parameter closing tool with no output schema, the description covers the essential contexts: default behavior, what happens after closing, and a data-loss warning. It lacks only edge-case details like behavior when closing the last tab or handling invalid IDs, but these are not critical for basic use.

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 input schema already has 100% coverage, describing the optional 'id' parameter and noting that omission closes the current page. The description reinforces this by mentioning the default current tab, but adds no additional parameter-specific semantics beyond what the schema provides.

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's purpose: to close browser tabs, with the default being the current active tab. This distinguishes it from sibling tools like web_tab_switch, web_tab_new, and web_tab_list by defining a distinct close action.

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 when a tab needs to be closed and clarifies the default behavior, but it does not explicitly compare with alternatives or state when not to use this tool. There is no mention of using web_tab_switch for merely switching tabs, so alternatives are not addressed.

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

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

无任何注解，描述自行声明“只读操作”，提供了安全/副作用方面的关键信息。但未说明返回格式、排序、空标签页列表行为，或是否包含标签页 ID，行为透明度有限。

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?

描述仅两句，第一句亮出核心行为，第二句补充权限说明，信息密度高且无冗余，结构适合快速理解。

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?

工具简单、无参数，但无输出 schema 且无注解，描述应更完整说明返回结构。虽然提到 URL 和标题，但未涉及标签页唯一标识或返回形式，对后续切换等操作可能不够充分。

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 为空，描述不涉及参数也无需补偿。按 0 参数基线评分为 4。

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?

描述使用明确动词“列出”，指定资源“全部标签页”，并说明包含 URL 与标题。这与打开、关闭、切换标签页等兄弟工具明显区分，目的清晰。

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?

描述没有说明何时使用该工具、何时不使用，或指出与 web_tab_new、web_tab_switch 等工具的关系。仅凭“列出全部标签页”间接暗示用途，缺少明确的场景指导。

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

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

With no annotations, the description carries the full burden. It discloses that the tab is created with optional URL, is activated by default, and may initiate network requests (permission note). However, it does not describe failure behavior, what the timeout parameter actually applies to, or any side effects on existing tabs, leaving gaps in behavioral understanding.

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 extremely concise: two sentences that front-load the main action and then provide a relevant permission note. Every sentence adds essential information with no redundancy or extra wording.

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 simple 3-parameter tool with no output schema and no annotations, the description covers the primary purpose, the activation behavior, and a network side effect. It is missing only a comparison to sibling tools and some detail on timeout semantics, but these are largely covered by the schema.

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%, so each parameter is documented in the schema. The description adds little beyond what the schema already states: '可带初始 URL' mirrors the url property, and '默认立即激活' mirrors the activate_tab default. No additional meaning is provided, so the baseline score 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 clearly states the action '新建一个标签页' (create a new tab) and specifies it can include an initial URL and be activated immediately. This distinguishes it from tab-management siblings like web_tab_switch and web_tab_close, though it does not explicitly differentiate from web_open, which could also involve opening a URL.

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?

No explicit guidance is given on when to use this tool versus alternatives such as web_open or web_tab_switch. The description only implies usage for creating a new tab, with no exclusions or comparative context, leaving the agent to infer the appropriate scenario.

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

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

With no annotations provided, the description carries the disclosure burden. It explicitly states '权限说明：只读操作' (read-only operation) and explains that switching makes subsequent actions target that tab. This is good context, though return behavior and error handling are not discussed.

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 two sentences, front-loaded with the primary action, and every sentence adds value. There is no redundancy or filler.

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 simple one-parameter tool with no output schema, the description covers purpose, usage context, and the read-only safety property. It is sufficiently complete for an agent to select and invoke it correctly, though a note on return value could have pushed it to 5.

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 input schema has 100% coverage with the id parameter described as the tab id from web_tab_list output. The tool description itself adds no extra parameter semantics, so the baseline score of 3 applies.

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 the specific verb+resource structure '切换活动标签页' (switch active tab) and clarifies that subsequent actions will act on that tab. This clearly distinguishes it from sibling tab tools like web_tab_new, web_tab_list, and web_tab_close.

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 phrase '后续动作作用到该标签页' provides clear context for when to use the tool, and the schema mentions that the id comes from web_tab_list output. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of disclosure. It transparently notes '发送键盘事件到当前页面' (sends keyboard events to the current page) and states the target is the focused element. However, it does not mention behavior when no element is focused, whether existing content is overwritten, or error conditions.

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 extremely concise: two short sentences, the first stating the action and the second clarifying permissions. It is front-loaded with the core purpose and contains no redundant or filler 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?

Given the tool's simplicity (2 params, no output schema), the description provides necessary context about the target (focused element) and mechanism (keyboard events). However, it lacks explicit guidance on when to use this versus web_fill or web_press, which are closely related siblings, so it is not fully 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 already covers both parameters with descriptions (100% coverage). The description adds value by explicitly connecting the delay parameter to the purpose of simulating real input rhythm ('可模拟真实输入节奏'), which enriches the parameter meaning beyond the schema's technical specification.

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 verb '键入' (type) and resource '当前聚焦元素' (currently focused element), and specifies the method '逐键输入' (key-by-key). This distinguishes it from sibling tools like web_fill (which likely fills a field directly) and web_press (which sends a single key press).

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 explicitly states that typing targets the currently focused element, providing clear context that the element must be focused first. It also mentions the ability to simulate real input rhythm, implying when this is useful. However, it does not explicitly name alternatives or exclusion criteria.

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

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

With no annotations, the description carries the transparency burden. It adds a permission note clarifying the wait is a read-only operation that generates no network requests, which is valuable behavioral context beyond the schema. It does not describe timeout failure behavior, but the timeout parameter is already documented in the schema.

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 compact, front-loaded with the core purpose, and each sentence earns its place: condition types, usage context, and a permission note. No redundant or filler content.

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 the 6 parameters are fully described in the schema and the tool is a straightforward blocking wait, the description covers the main use cases and safety profile. It lacks an explicit statement about timeout outcomes or return behavior, but this is not critical given the schema documents the timeout parameter and no output schema is expected.

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%, so the baseline is 3. The description restates the condition enum and their pairings (selector with selector/state, url with url_pattern, sleep with ms), but those details are already present in the schema's condition property description, adding no new semantic value.

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?

Description uses specific verb '按条件等待' (wait by condition) and explicitly enumerates the five supported conditions (load, networkidle, selector, url, sleep), clearly distinguishing it from sibling navigation tools like web_open or web_click.

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?

States it is suitable for slow page rendering or synchronizing after navigation, providing clear when-to-use context. It does not explicitly mention when not to use it or name alternatives, but the use case is sufficiently clear.

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