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

With no annotations provided, the description carries the full burden of transparency. It accurately describes the behavior (navigates back to the previous page) without hiding side effects or requiring additional 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 extremely concise, consisting of a single clear sentence. It omits unnecessary details and gets straight to the point.

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 that the tool has no parameters and performs a simple, well-defined action, the description is complete. An agent can understand exactly what the tool does without needing 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 tool has no parameters, and the description correctly reflects that no parameters are needed. The schema coverage is 100%, so nothing is left undocumented.

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: '浏览器后退到上一页' (browser goes back to the previous page). It specifies the verb (go back) and the resource (browser/page), and it is distinct from sibling tools like browser_forward.

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 for when to use the tool (when the user wants to navigate to the previous page). It does not explicitly mention alternatives, but the context is unambiguous and the action is self-explanatory.

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 disclosing behavioral traits. It mentions '按顺序执行' (execute in order), which is a key behavior, but it does not describe potential side effects, failure handling, or how the order affects the browser state. Additionally, the sentence '限时免费中' (limited time free) is irrelevant and distracts from behavioral transparency.

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 short but includes an irrelevant marketing phrase '限时免费中' (limited time free) that does not help the agent understand the tool. This extra content wastes space and violates the principle that every sentence should earn 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 description gives concrete examples of operations (open web pages, click, fill, extract, wait) which helps the agent understand the range of actions. However, it does not explain the structure of the 'steps' parameter beyond what the schema already provides, nor does it mention edge cases like invalid actions. Given the schema richness, this is adequate but not exceptional.

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 provides 100% coverage of the one parameter (steps) with a description of each property and the overall list. The tool description adds no extra meaning beyond what the schema already states, 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 clearly states the tool's purpose: batch execution of automation operation sequences. It mentions the specific verb '批量执行' (batch execute) and the resource '自动化操作序列' (automation operation sequence), and it specifies that operations are executed in order. This distinguishes it from the individual sibling tools like browser_click or browser_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 does not provide explicit guidance on when to use this tool versus the individual sibling tools. It implies batch usage but does not state conditions like 'use this when you need to perform multiple steps' or 'use individual tools for single actions.' No alternatives are mentioned.

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, and the description only states the basic action. It does not disclose side effects (e.g., triggering events), error behavior for missing elements, or whether it affects disabled fields.

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, concise sentence that directly conveys the tool's purpose without unnecessary words or repetition.

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 action, the description is adequate, but it omits potential edge cases (e.g., clearing a non-input element, or the effect on related UI state). Still, it is sufficiently complete for the tool's simple nature.

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 describes the parameter 'selector' as a CSS selector, and the tool description adds no additional context or clarification about its usage or expected format.

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: clearing the content of an input field. It uses a specific verb and resource, making it distinct from sibling tools like fill or 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?

The description does not explicitly mention when to use this tool versus alternatives, such as when to use fill with an empty string. Usage must be inferred from the tool's name and description.

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 full responsibility for behavioral disclosure. It only states that it clicks an element, but does not disclose whether the click is awaited, whether the element must be visible, whether it triggers navigation, or any side effects. This is minimal for a browser interaction 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?

The description is a single concise sentence in Chinese, easy to parse and free of redundancy. However, its brevity sacrifices useful context, though that is captured under other dimensions.

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 tool with three parameters and full schema coverage, the description is minimal. It lacks usage guidance and behavioral details, which are important for a browser automation tool. The agent would need to infer when to use it and what happens on click, so completeness is insufficient.

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 each parameter (text, selector, rightClick) clearly described. The description adds no additional semantic meaning beyond what the schema offers, so a 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 states the action (click) on a resource (page elements) and mentions two matching modes (CSS selector or text). It is clear about what it does, but it does not distinguish itself from the sibling tool browser_clickAt, which likely has a similar purpose.

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. There is no mention of when to prefer browser_click over browser_clickAt or other click-related tools, leaving the agent to infer selection from parameter names alone.

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 mentions that clicking by coordinates is for elements not locatable by CSS, but does not disclose details such as whether the click is simulated, whether it scrolls the element into view, or whether it triggers events. This is moderate transparency.

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, stating the action, the condition for use, and example scenarios in a compact manner. No redundant words.

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 adequately covers the tool's purpose and appropriate usage scenarios. It lacks details about edge cases (e.g., coordinates outside viewport) or return behavior, but given the simplicity of the operation, it is largely 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 provides descriptions for all parameters (coordinates relative to viewport, button options, click count). The tool description does not add extra semantic context beyond the schema, so a 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 tool clicks at specified coordinates on the page, and provides typical use cases such as sliding captchas, popups, and canvas elements. It also distinguishes itself from element-based clicking by noting it is for elements that cannot be located with CSS selectors.

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 explains when to use this tool: when elements cannot be located via CSS selectors, and for scenarios like sliding captchas, popups, and canvas. This gives clear guidance on choosing this tool over alternatives like browser_click.

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 and explicitly discloses key side effects: it does not clear the browser instance, and the next operation will automatically create a new page. This is sufficient transparency for the tool's 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 a single concise sentence that directly conveys the action and its key behavioral consequence without unnecessary detail.

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 simplicity of the tool, the description provides enough context for an agent to know what happens when it is invoked. No output schema exists, and no return value explanation is necessary for this destructive action.

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 no parameters, and the schema coverage is trivially 100%. The description adds no parameter-specific meaning, but none is needed because there are no 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?

The description clearly states the action: close the current page. It distinguishes itself from other tab-related tools by specifying that the browser instance is preserved and a new page will be created automatically on the next operation.

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 this tool: when you want to close the active page but keep the browser session alive. It does not explicitly compare with browser_closeTab, but the behavioral note about auto-creating a new page on the next operation provides practical guidance.

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 discloses the automatic switch to the previous tab, which is a key behavior. However, it does not mention side effects like closing the last tab, invalid index handling, or whether confirmation is required. No annotations provide additional transparency.

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, using only two clauses to convey the action and default behavior. No unnecessary words 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 tab-close operation but lacks context about edge cases (e.g., single tab, invalid index) and does not mention how it interacts with other tab-management tools. It is clear but not exhaustive.

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 parameter 'index' is fully described in the schema with its default behavior. The tool description does not add extra meaning beyond the schema, so it meets the baseline for 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 (closing a tab) and the resource (browser tab), and implies the default behavior of closing the current tab. It distinguishes from sibling tools like browser_newTab and browser_switchTab by focusing on the close operation.

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 on when to use this tool versus alternatives (e.g., when to close a tab vs. switching). The description does not mention scenarios where this is preferred or any prerequisites.

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 of behavioral disclosure. It does not mention side effects of the 'clear' parameter (e.g., clearing the buffer) or describe the return format (e.g., an array of log entries). The description only states what it fetches, not what the tool does beyond that.

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, concise sentence that front-loads the core action. There is no fluff or redundant information; 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?

The tool is simple, but the description omits critical context: it does not specify the return type (e.g., an array of log strings) or behavior when there are no logs. It also does not explain the 'clear' parameter's effect in the description, leaving the agent to infer it solely from the schema. Given no output schema and no annotations, this is a significant gap.

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 provides a full description of the 'clear' parameter (whether to clear the log buffer after retrieval), covering 100% of the parameter meaning. The tool description does not add any extra semantic value beyond what the schema already explains, 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 clearly states the verb (获取/get) and resource (页面控制台日志/page console logs), and specifies the log types (console.log/error/warn). It distinguishes itself from siblings like browser_getTitle or browser_getHTML by focusing on console output, making its 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 provides no guidance on when to use this tool versus alternatives. For example, it does not clarify when to prefer browser_console over browser_evaluate (which could also access console via JS) or mention any prerequisites. The intended usage context is only implied by the name and description.

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?

无注释，描述承担全部责任。仅说明删除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?

对于简单删除工具，无输出schema，参数少且schema覆盖完整，描述基本足够。但缺少行为细节（如删除特定cookie的条件），且无注释，整体可接受但非完备。

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覆盖100%，两个参数name和domain都有清晰描述，描述本身未添加额外格式或语义信息。基线为3，因为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?

描述明确说明工具用于删除Cookie，并具体说明不传参数时的行为（删除所有），动词和资源清晰。名称也直观，与兄弟工具如browser_getCookies区分明显，但未明确提及与browser_clear等其他清除工具的区别，略降一分。

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 full responsibility for disclosing side effects. It only states the action without mentioning post-drag events, state changes, or any potential consequences, leaving the agent with limited understanding of the tool's full 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 a single, concise sentence that conveys the core function without any unnecessary words. It is well-structured and to the point.

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 four parameters and no output schema, the description is minimally adequate. It identifies the action and the target, but lacks additional context about how the drag is performed (e.g., duration, steps, or interaction with the page) that might be useful in complex automation scenarios.

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 all four parameters with descriptions, including the mutual exclusivity between offset and targetSelector. The description itself adds no extra meaning beyond the schema, but since coverage is 100%, 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 'drag element to target position' clearly states the action (drag) on a resource (element), and it is distinct from sibling tools like click or hover. It could be more specific about the drag mechanics, but it is 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?

No guidance is provided on when to use this tool versus alternatives such as mouseMove or click. The description does not mention conditions, prerequisites, or scenarios where dragging is preferred.

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 bears the full burden of behavioral disclosure. It states that code is executed and a result is returned, but it does not disclose that executing arbitrary JavaScript can have side effects (e.g., navigation, DOM mutations, network requests) or that it may be irreversible. It also does not clarify whether the execution is synchronous or how complex results (objects, promises) are serialized. This is a significant gap for a code-execution 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?

The description is a single, concise sentence that directly states the action and result. It is front-loaded with the primary purpose, and there is no unnecessary elaboration. While it is minimal, it is efficient for a tool with one parameter and no annotations.

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 that this is a high-complexity tool (arbitrary code execution) with no output schema, the description is insufficiently complete. It does not explain the return value's format, potential failure modes, or safety considerations. For example, an agent would benefit from knowing whether the result is a JSON-serialized value, whether promises are awaited, or whether the code runs in the page's context. The description only offers the basic action and result without the details needed for confident invocation.

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%, and the parameter 'code' is described as '要执行的 JS 代码' (JS code to execute). The tool description adds no further meaning beyond what the schema already provides, so the baseline of 3 applies. No compensation is needed, but no extra value is added either.

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: executing custom JavaScript code in the page and returning the result. This specific verb-resource combination (execute JS) distinguishes it from sibling browser tools like browser_extract or browser_click, which perform different actions. No ambiguity remains about what the tool does.

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 no guidance on when to use this tool versus alternatives. With over 30 sibling tools, there is no indication that this is the appropriate choice for running arbitrary code, nor any mention of when it should be avoided (e.g., if a more specific browser action would suffice). The agent must infer usage entirely from the tool's purpose.

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 behavioral traits. It does not mention side effects like file creation, overwriting, permissions, or whether data is returned when no filePath is given. The phrase '限时免费中' is promotional and irrelevant. There is no contradiction with annotations (none exist), but the description fails to disclose any behavioral details beyond the basic 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 short and front-loads the purpose in the first sentence. However, the second sentence '限时免费中' (limited-time free) is promotional and not useful for an agent deciding when to call the tool. This is minor noise, but the overall structure is efficient and clear.

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?

With no output schema and no annotations, the description needs to cover expected return values, edge cases, and usage context. It does not mention what happens when filePath is omitted (output to result), the default format, or that selector is required. It also lacks guidance on when this tool is preferred over siblings. The description is too sparse for an agent to call it correctly without inspecting the schema closely.

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%, with each parameter (selector, format, filePath) having a description. The tool description adds no additional meaning about parameters; it does not explain what the selector targets (tables/lists), the default format, or the behavior of filePath. Since the schema fully documents parameters, the baseline of 3 applies; the description provides no extra 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?

The description states a clear verb ('export') and resource ('page data') with output formats (CSV/JSON). It is not a tautology and conveys the core action. However, it does not explicitly mention that it targets tables/lists (which is in the schema's selector description) nor does it differentiate from sibling tools like browser_extract, which might also extract data. The promotional phrase '限时免费中' adds no purpose clarity.

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 no guidance on when to use this tool versus alternatives. It does not say 'use this when you need to save data to a file' or contrast with browser_extract or browser_evaluate. The description provides no context for selection among siblings, leaving the agent to infer usage from the schema.

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 for behavioral transparency. It implies a read-only operation ('extract') but does not disclose potential side effects, failure modes, or authorization requirements, offering only minimal insight.

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, concise sentence that is front-loaded with the primary action and object. It contains no fluff or redundant information.

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 simplicity of the tool and the absence of an output schema, the description is somewhat incomplete. It does not specify the return format (e.g., string of text or attribute value) or behavior when no element matches, but the core purpose is clear enough 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 fully describes both parameters (selector and attribute) with clear explanations, achieving 100% coverage. The description adds no additional meaning beyond the schema, so a 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 tool extracts page text content, a specific verb-object pair. It is distinguishable from siblings like getHTML and getTitle, though it does not explicitly mention attribute extraction which is defined in the schema.

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 no guidance on when to use this tool compared to alternatives such as getHTML or evaluate. There is no mention of scenarios where this tool is preferred or dispreferred.

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?

There are no annotations. The description mentions simulating real user input with a delay, which provides some behavioral insight, but it does not disclose side effects such as the default clearing behavior (though that is in the schema) or whether the action is reversible. Since no annotations are present, the description carries full responsibility and falls short of full transparency.

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 directly stated in two short sentences. It includes the essential action and a key behavioral characteristic (delay) without unnecessary detail, making it easy to parse.

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 (four parameters) and lack of an output schema, the description together with the schema provides enough context for an agent to call it correctly. It does not explain return values, but that is not strictly necessary since the tool likely returns nothing or a simple confirmation.

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 provides complete descriptions for all four parameters (selector, value, clear, delayMs), offering 100% coverage. The description adds no extra semantic meaning beyond what the schema already defines, so it meets the baseline but does not improve it.

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 fill an input box with simulated real user input, including a delay. This distinguishes it from sibling tools like browser_click, browser_clear, and browser_pressKey, which have different actions.

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 the tool is for filling text inputs but does not explicitly explain when to use it over alternatives like browser_pressKey or browser_clear. No use-case guidance is provided, so the agent must infer the appropriate 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action but does not mention potential outcomes, such as what happens if there is no forward history, whether it affects the current tab, or any prerequisites. This is insufficient for a navigation tool in a context with many siblings.

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, concise sentence that front-loads the core action. It is efficient and free of extraneous words. While it is minimal, it is appropriately sized for a tool with no parameters, though it could benefit from a brief mention of edge cases.

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 is incomplete. It lacks context about what happens when there is no forward history, whether it operates on the current tab or the whole browser, and how it relates to browser_back. Given the large set of sibling tools and the absence of annotations or output schema, this is insufficient for an agent to call it correctly in all scenarios.

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, so the baseline score is 4. The description doesn't need to elaborate on parameters, and the empty schema already covers everything. No additional parameter information is required.

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 states the action clearly: 'browser forward to next page' in Chinese. It identifies the resource (browser) and the specific operation (forward navigation), distinguishing it from the sibling browser_back. However, it doesn't elaborate on what 'next page' means (e.g., history forward) or provide any additional context that would help differentiate it from other navigation 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?

There is no guidance on when to use this tool versus alternatives. It doesn't mention when to use forward vs. back, or when it's appropriate to use this over browser_reload or other navigation tools. The description leaves all usage decisions to the agent's inference.

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 states the tool retrieves position and size information, implying a read-only operation, but it does not specify return format, potential errors, or coordinate system (viewport vs. document), leaving some behavioral details undisclosed.

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 the primary action stated first and a brief explanatory clause for context. It is not verbose and contains no redundant information.

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 (one parameter, no output schema), the description provides sufficient context to understand what it does and when to use it. It lacks explicit details about the return structure, but this is not critical for basic usage.

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 defines the 'selector' parameter as a CSS selector, covering its basic meaning. The description adds minimal extra semantic value beyond that, such as tying it to element location, which is already inferred from the tool's purpose.

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 retrieves element position and size, and mentions its use case for calculating click coordinates and swipe distances. This distinguishes it from sibling tools that perform actions like clicking or dragging.

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 indicates when to use the tool (for computing coordinates before actions like clicks or swipes), providing clear context. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of being fully explicit.

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 implies a read-only action but does not disclose potential sensitivity of cookie data or any side effects. Basic but not misleading.

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, concise sentence that directly conveys the tool's purpose without any unnecessary words or structures.

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 getter, the description is sufficient. It covers the action and the optional parameter. No output schema is present, but the return (cookies) is implied and 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 'domain' parameter is described with its optionality and purpose ('按域名筛选'), adding meaningful clarity beyond the schema type. Schema coverage is 100%, and the description enriches it.

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 '获取当前页面的所有 Cookie' (get all cookies of current page), using a specific verb and resource. It distinguishes itself from sibling tools like browser_deleteCookies.

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 on when to use this tool versus alternatives. The description does not mention deleteCookies or other related tools, nor any conditions for retrieval.

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 bears the full burden. It indicates a read operation ('get') with no side effects mentioned, which is consistent with a getter. However, it does not specify behavior for invalid selectors or empty results, leaving minor ambiguities.

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, concise sentence that fully conveys the tool's function without superfluous details. It is well-structured and immediately understandable.

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 retrieval tool, the description adequately covers its core behavior. It lacks explicit error scenarios or return format, but these are not critical for a basic getter and the description leaves no major gaps in understanding.

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. The descriptions add meaningful context: 'outer' clarifies inclusion of the element's own tag and its default, while 'selector' explains that an empty value retrieves the whole page. This goes beyond basic type 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 clearly states that the tool retrieves HTML source of the current page or a specified element, making its purpose unmistakable. It is distinct from sibling tools like browser_getTitle or browser_screenshot, which serve different retrieval purposes.

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 obtaining HTML but does not explicitly contrast it with alternatives such as browser_extract or browser_evaluate. There is no direct guidance on when to prefer this tool over others, though the purpose is self-evident.

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. It makes the read-only nature explicit by saying 'get,' but does not mention potential errors (e.g., if no page is loaded) or side effects. For a simple getter, this is adequate.

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?

A single, concise sentence that fully conveys the operation without unnecessary words.

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 zero-parameter, zero-output-schema getter, the description is complete. No additional context is needed for correct invocation.

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 takes no parameters, so the baseline applies. The description adds no parameter-level details because there are none to clarify.

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?

Clearly states the action (get) and the resource (the current page's title). It distinguishes itself from sibling tools like browser_getUrl and browser_getHTML by specifying the exact data returned.

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 tool's purpose is self-evident, but the description does not explicitly mention when to prefer it over other getter tools or any conditions. However, given the distinct resource, no ambiguity arises.

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 accurately states the primary action (getting the URL) but does not disclose any potential side effects, permissions, or limitations. Since no annotations are provided, the description carries the full burden, and it only covers the surface behavior without deeper transparency.

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, concise sentence with no extraneous information. It is direct and well-structured, containing only the essential statement of functionality.

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 simplicity of the tool (no parameters, no output schema), the description provides enough context to understand its purpose. It lacks additional details such as whether it works across iframes or how the URL is returned, but these are not critical for a basic getter 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 tool has zero parameters, so the schema coverage is effectively 100%. The description does not need to explain non-existent parameters. Per the baseline for 0 parameters, a score of 4 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 that the tool retrieves the full URL of the current page, which is a specific and unambiguous action. It distinguishes itself from the sibling tools by naming a unique resource (URL) and a specific verb (get).

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 no guidance on when to use this tool versus the many sibling tools. It does not mention any conditions or alternatives, leaving the agent to infer appropriate usage from the name alone.

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 implies a read-only operation by saying 'get', but does not explicitly state side-effect-free behavior or any prerequisites like a loaded page.

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, concise sentence that directly communicates the tool's purpose without unnecessary words or repetition.

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 getter, the description is sufficient. It does not specify the return format, but the lack of parameters and clear purpose make the tool reasonably complete for typical usage.

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, so the baseline is 4. There are no parameter descriptions needed, and the description does not introduce any parameter-related ambiguity.

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 the tool gets the current page's viewport size and scroll position, using a specific verb and resource. It is easily distinguishable from sibling getters like getUrl and getTitle.

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 about when to use this tool versus alternatives, such as screenshot or evaluate. The description only states what it does, not when it should be preferred.

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?

There are no annotations, so the description carries the full burden. It does mention the CSS hover effect, which is a behavioral detail, but it omits other relevant aspects such as error handling, waiting behavior, or visibility requirements.

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, clear sentence with no superfluous words. It is well-structured and easy to understand.

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 simplicity of the tool, the description covers the core purpose but lacks details about return values (though no output schema is defined) and potential side effects or requirements. It is adequate but not thorough.

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 provides descriptions for both parameters (text and selector) with the priority note. The tool description adds no additional semantic meaning beyond that, so it remains at the baseline for full 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 (hover the mouse) and the effect (triggers hover CSS effect). It distinguishes itself from other browser actions like click or fill by specifying the hover 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 does not mention when to use this tool versus alternatives, nor does it provide guidance on choosing between the text and selector parameters beyond the parameter descriptions. No explicit comparison to sibling tools 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?

Without annotations, the description bears the full burden of explaining behavior. It states that subsequent operations execute within the iframe and that passing 'main' switches back, providing key behavioral insight. It does not disclose all potential side effects, but the core behavior is clear.

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, using a single sentence with two clear clauses. It is well-structured and contains no unnecessary information.

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 (one parameter, no output schema), the description provides complete context: purpose, usage, parameter semantics, and behavioral effect. Nothing essential is missing.

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 single parameter 'selector' is described as the iframe's CSS selector, with a special value 'main' to switch back. This adds significant meaning beyond the schema's type hint and fully clarifies parameter 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 the tool's function: switching to an iframe context or back to the main page. It uses specific verbs and names the resource, effectively distinguishing it from sibling 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?

The description explains when to use the tool (to execute subsequent operations within an iframe) and how to return to the main page using 'main'. It implies usage context but does not explicitly mention alternative tools 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?

The description mentions the behavioral trait of simulating human trajectory through segmented movement, but it does not disclose potential side effects (e.g., triggering hover events, coordinate system, or viewport constraints). With no annotations provided, more transparency would be expected.

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, using only two sentences to convey the essential purpose and one additional feature. No redundant wording or unnecessary details are 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?

For a simple action with no output schema, the description covers the core behavior and the optional parameter. However, it does not specify the coordinate system (e.g., viewport vs. page) or whether the tool auto-scrolls to coordinates, which could be a minor gap in full context.

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 provides descriptions for all three parameters (100% coverage). The description adds no extra semantic information beyond what the schema states, so it meets the baseline but does not exceed it.

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 (simulate mouse moving), the target (specified coordinates), and the scope (supporting segmented movement for human-like trajectory). It is specific and distinguishes the tool's function without ambiguity.

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 given about when to use this tool versus alternatives like hover or clickAt. The description lacks any explicit or implied usage conditions, leaving the agent without information on when to prefer this tool.

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 does not disclose any behavioral details such as whether the new tab becomes active or if it is a non-destructive operation. No annotations are present to supplement this.

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 concise sentence with no redundant words. It is well-structured and to the point.

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 tool with a clear schema and no output, the description is mostly adequate. However, it omits mention of the URL parameter's effect, which could lead to a partial understanding of the tool's full capability.

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 fully documents the optional 'url' parameter. However, the description's phrase 'blank tab' could imply that no URL is ever opened, potentially conflicting with the parameter's purpose. The description adds no extra clarity 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 the tool's function: opening a new blank tab. It is specific and distinguishes this tool from siblings like switchTab or closeTab.

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios where a new tab is preferred over switching tabs or opening a URL in an existing tab.

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 discloses that the operation returns a Base64-encoded PDF, which is a key behavioral aspect. However, it does not explicitly state whether the operation is read-only or if any side effects occur, though export implies no page modification. Since no annotations are present, more detail would improve transparency.

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 concise sentence that conveys the essential purpose. No superfluous words 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 covers the main functionality and output format, and all parameters are described in the schema. It does not mention error handling or edge cases, but for a simple export tool it is 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?

All three parameters (scale, format, landscape) have descriptions in the schema, so coverage is 100%. The description does not add additional semantics beyond the schema, e.g., valid ranges or interactions between parameters, so it stays at the baseline.

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 identifies the action (export), the resource (current page), and the output format (PDF with Base64 encoding). It differentiates from siblings like browser_screenshot by specifying PDF, making its 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 does not specify when to use this tool versus browser_screenshot or browser_export. No conditions or alternative comparisons are provided, so an agent lacks guidance on selection.

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 present, so the description carries the responsibility. It effectively discloses the supported keys and combinations, but does not mention potential side effects (e.g., requiring focus, event propagation) or what happens after pressing.

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, front-loaded with the action, and uses two clear sentences. It includes examples without unnecessary 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 keyboard action, the description provides sufficient context, including key examples and combination syntax. It does not mention return values or edge cases, but these are not critical for this tool's basic usage.

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 the parameter with a description and examples. The tool description repeats the same information, adding little new semantic value beyond reinforcing the acceptable values.

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 action (press keyboard keys) and provides a list of supported keys and combinations, making its purpose unambiguous and distinct from sibling tools like click or 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 does not explicitly explain when to use this tool versus alternatives, but the action is self-explanatory and the examples imply common keyboard interactions. No direct comparison or exclusions are 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 does not disclose potential side effects such as loss of form data or reliance on cache. While the parameter description mentions cache behavior, the tool description itself omits behavioral details that could affect the user.

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—a single sentence—and directly states the purpose without any unnecessary words. It is appropriately sized for the simple action and front-loaded with the core action.

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 browser action, the description is adequate: it clearly specifies the target ('current page') and the action. It could benefit from mentioning that it operates on the active tab, but given the simplicity and sibling context, it is largely 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 provides full coverage for the single parameter (ignoreCache) with a clear description. The tool description adds no extra meaning beyond the schema, aligning with the baseline of 3 for 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: 'Refresh the current page.' It names the specific verb (refresh) and the object (current page), making it unambiguous and distinct from sibling tools like browser_reset or browser_newTab.

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. There is no mention of appropriate contexts or scenarios where refreshing is necessary or preferable.

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 and clearly discloses the destructive behavior: '关闭所有页面和浏览器进程' (closes all pages and browser processes) followed by a restart. This is transparent about 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 two concise sentences, front-loading the action and then giving the purpose. Every sentence contributes meaning.

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 parameters and no output schema, the description fully covers purpose, usage condition, and side effects. It is complete for an agent to decide when and how to call 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?

There are zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter info, but none is needed.

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 states the specific verb '重置' (reset) and resource '浏览器实例' (browser instance), and explains it closes all pages and processes and restarts. This clearly distinguishes it from sibling tools like 'reload' or '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?

It explicitly specifies the use case: '用于浏览器卡死或状态异常时' (for when the browser is frozen or in an abnormal state). It doesn't explicitly name alternatives, but the condition implies not using it for normal navigation.

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 reveals a conditional behavior: it may navigate to a new URL if provided, otherwise it uses the current page. It does not mention other side effects like cookie changes or history updates, and since no annotations are present, it carries the full burden of transparency, resulting in a moderate score.

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, directly to the point, with no unnecessary words. It efficiently communicates the core function and the conditional behavior, 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?

It covers the main use cases (opening a URL or screenshotting current page) and mentions the output format (PNG). It lacks details on error handling or specific behavior of waitMs/fullPage, but given the simple nature of the tool, it is reasonably 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 includes descriptions for all three parameters (url, waitMs, fullPage). The tool description adds little beyond repeating the meaning of url; it does not add new information about waitMs or fullPage, so it stays at the baseline given the 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 tool's function: take a screenshot, optionally after opening a URL. It also clarifies the behavior when a page is already open via the conditional phrase. However, it does not explicitly differentiate it from sibling tools like screenshotElement, but the mention of 'current page' and 'PNG' provides implicit distinction.

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 basic guidance: if a page is already open, it screenshots the current one; otherwise, it can open a URL first. It does not explicitly name alternatives or conditions for when to use this tool over others, but the conditional note gives a practical usage pattern.

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 for behavioral disclosure. The description only states the action without mentioning any side effects, prerequisites, or how the screenshot is returned. It does not mention that the element may need to be visible or that the optional 'scrollIntoView' parameter could affect the capture. This lack of behavioral detail is a significant gap.

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, concise sentence that front-loads the primary action and provides illustrative examples. It is efficient and easy to scan, with no unnecessary words 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?

Given the simplicity of the tool, the description provides enough context for basic usage, but it lacks any mention of the output format or what the agent should expect as a return value. Since there is no output schema and no annotations, the description should clarify that a screenshot image or file is returned, but it does not. This leaves a moderate gap.

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 includes descriptions for both parameters with 100% coverage, so the baseline is 3. The tool description does not add any further meaning beyond what the schema provides. Since the schema is sufficient, no additional points are warranted.

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: '截取页面中某个元素的截图' (take a screenshot of an element on the page), and gives examples such as button, image, and area. This unambiguously distinguishes it from the sibling tool 'browser_screenshot' which likely captures the full page.

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 screenshot of a specific element is needed, but it does not explicitly compare with alternatives like the full-page screenshot or PDF sibling tools. There are no clear conditions or exclusions stated, leaving the user to infer when to choose this tool over others.

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 bears full responsibility for disclosing behavioral details. It does not mention that scrolling operates on the current page, potential side effects, or how it interacts with iframes or viewport boundaries. The behavior is not fully 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?

The description is extremely concise and to the point, with no unnecessary words or redundant information. It effectively communicates the core functionality in two short sentences.

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 that the schema covers all parameters and no output schema exists, the description is mostly complete. However, it lacks details about the scope of scrolling (e.g., main page vs. iframe) and any return behavior, leaving some contextual gaps for the 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?

The schema already provides descriptions for all three parameters (direction, amount, selector), including the precedence of selector over direction. The tool description adds no extra semantic meaning beyond what is in the schema, so a 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 tool scrolls the page and supports two modes: directional scrolling or scrolling to an element. It is unambiguous, though it does not explicitly name sibling tools to distinguish itself from them.

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 compared to alternatives like browser_back, browser_reload, or browser_iframe. It only states what it does, leaving the agent to infer usage context from the tool name and sibling list.

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 burden. It states the action but does not detail side effects such as whether change events are triggered, if prior selections are cleared, or behavior when no matching option is found. This is a moderate gap.

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 concise sentence that effectively conveys the core purpose without unnecessary detail.

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 and schema fully cover the parameters and action. It omits edge cases like multiple matches or error handling, but for a simple select operation, it is reasonably complete. No output schema exists, so no return value explanation is needed.

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?

All parameters have descriptions (schema coverage 100%), and the descriptions clarify their roles. However, they do not explain the mutual exclusivity or priority (value over label over index), which is important for correct usage. This adds some meaning but not full clarity.

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 (select an option) and the target resource (a dropdown `<select>` element). It is distinct from sibling tools like `browser_click` or `browser_fill` which handle other interactions.

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 use for dropdown selection, and there is no alternative select-specific tool among siblings, so it is the obvious choice. However, it does not explicitly mention when not to use it (e.g., for non-select elements), but this is implied by the resource mention.

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 reveals nothing about the tool's behavior beyond the name. It does not mention side effects, prerequisites, error conditions, or what happens upon success or failure, leaving the agent without critical expectations.

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 short and to the point, but it provides no structured information or additional context. It is not verbose, but it also does not add value beyond the tool name, making it minimally adequate.

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?

With no annotations, no output schema, and a one-phrase description, the tool lacks essential contextual information. An agent would not know when to prefer this over sibling tools, what inputs to provide beyond the default, or what to expect in return, making it incomplete for reliable 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 schema fully describes the only parameter 'selector' with its default value and meaning. The description adds no additional semantic detail, so the baseline score of 3 is appropriate given the 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 of submitting a form, which is a specific verb and resource. However, it does not distinguish this from other browser actions beyond the name itself, missing the differentiation that would warrant 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?

No guidance is provided on when to use this tool versus other browser actions like click, fill, or evaluate. The description offers no context or examples to help an agent decide when submission is appropriate.

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 and no mention of side effects, error behavior, or whether the browser waits for the tab to be ready, the description only states the bare 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 a single, focused sentence with no filler, making it easy to parse.

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 tab-switch tool, the description plus schema is largely complete, though it would benefit from noting out-of-range or invalid index behavior.

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 documents the 'index' parameter and its 0-based meaning, so the description adds no extra parameter semantics beyond what is already available.

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 'Switch to the tab at the specified index (0-based)' states a specific action and resource, clearly distinguishing this from sibling tools like newTab and closeTab.

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 given about when to use this tool versus alternatives, nor about how the index relates to the current tab list or what happens with an invalid index.

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 bears the full burden of behavioral disclosure. It only says 'wait for a period or element appear' and does not mention the 'disappear' mode, the timeout behavior (e.g., throwing on timeout), or whether it blocks execution. This is a significant gap for a tool with four parameters.

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?

A single, concise sentence that clearly front-loads the core purpose. No wasted words; it is efficient and easy to parse.

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 wait tool, the description is mostly sufficient, but it omits critical context like what happens when a timeout occurs, how the disappear parameter affects behavior, and whether it returns any value. Given the absence of an output schema and annotations, these gaps make it incomplete.

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% with each parameter described, so the baseline is 3. The description adds minimal value beyond the schema, only hinting at the ms/selector split but not explaining timeout or disappear. It does not compensate for the missing behavioral details.

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: wait for a duration or for an element to appear. It uses a specific verb (wait) and resource (time/element), and it stands apart from all sibling tools since none other handles waiting. The mention of 'element appear' covers the primary mode, though it omits the disappear option, which is minor.

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 explicit guidance on when to use this tool versus alternatives, but there are no direct alternatives among siblings. It is implied that this is the tool for any waiting need. However, it does not mention prerequisites or typical scenarios like waiting for navigation or AJAX completion, so the guidance is basic.

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