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

Annotations only provide readOnlyHint=false. The description adds meaningful behavioral context: it is real input at CDP level (not JS simulation), and the steps schema mentions human-like typing rhythm (30~90ms) when interval is omitted. This goes beyond annotations. It doesn't disclose failure modes or page-focus requirements, but the core behavioral nature is clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences plus a compact list of typical usage examples. The purpose is front-loaded, and every sentence adds value. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (many action types), but the schema covers each action thoroughly. The description adds the key differentiator (real input) and typical sequences. It doesn't mention when to fall back to simpler siblings, which would be useful but is not critical. Given the rich schema, the description is adequate.

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% – the steps parameter already documents every action type and its parameters in detail. The description adds semantic guidance on how to combine actions (e.g., 'type 输入文本前先 move_to/click 输入框获得焦点'), which enriches the schema. This goes beyond baseline 3 by providing usage patterns that clarify parameter roles.

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 specific verb and resource: '按顺序执行一串真实鼠标/键盘操作' (execute a sequence of real mouse/keyboard operations). It explicitly distinguishes itself from JS simulation ('CDP Input 事件级别，非 JS 模拟'), which differentiates it from sibling tools like element_click or run_js. The typical usage patterns (move_to then click, hold+move+release drag, type after focus) make the purpose concrete.

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 of when to use the tool through typical usage examples (drag, focus before typing). However, it does not explicitly name alternatives or state when NOT to use it (e.g., for a single click, element_click might be simpler). The guidance is implied rather than explicit, but the examples give strong situational cues.

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 the operational sequence: real-click the input to open the portal calendar, then click the target date. It does not mention error scenarios or side effects, but the non-read-only annotation and click description provide reasonable transparency for a simple 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, concise sentence that directly states the tool's function without unnecessary words or repetition. It is well-structured 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 click-based date selection tool, the description sufficiently explains the core behavior. It omits return-value details, but given the full schema coverage and low complexity, the overall context is adequately 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 parameter descriptions in the schema are complete (100% coverage) with clear details for date format, timeout, and how to obtain element_id. The main description adds no extra parameter information, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action: it operates an AntD DatePicker by clicking the input to open the calendar and then clicking the target date. This makes the tool's purpose unambiguous and distinguishes it from other AntD interaction 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 identifies the target component (AntD DatePicker) but does not explicitly compare with sibling tools or state when to choose this tool over alternatives. The use case is implied rather than explicitly guided.

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 reflects the read-only nature of the operation by indicating it expands and lists options, without suggesting any modification. It does not describe edge cases or failure modes, but the core behavior is transparently stated.

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, containing only the essential action, object, and usage hint. It avoids redundant wording and is well-structured for quick comprehension.

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 states the output as 'all currently visible option texts,' which defines the expected result sufficiently. However, it does not mention whether additional data such as option values are included, and the available output schema is not shown in the prompt. This leaves a small gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Every parameter is described in the schema: tab_id is the tab identifier, timeout is the wait duration for the popup, and element_id is the Select element identifier. Schema coverage is complete and each description adds meaningful context.

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 expands an AntD dropdown select and lists all currently visible option texts, and explicitly positions it as a precursor to antd_select. This leaves no ambiguity about the tool's core function.

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 direct usage guidance by stating it should be used before antd_select. It does not elaborate on when it should or should not be used relative to other select-like siblings, but the primary workflow hint is clear and actionable.

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?

Annotations only provide readOnlyHint: false, so the description carries the behavioral burden. It discloses that the tool automatically finds visible .ant-modal, targets footer or confirm areas, and performs a real click. It also implicitly includes waiting via the timeout parameter. This adds useful behavioral detail without contradicting annotations.

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?

Two sentences with no wasted words. The core purpose and mechanism are front-loaded, and examples are concise. It is appropriately sized for the tool's simplicity.

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 narrow scope, an output schema, and full parameter documentation, the description covers the essential behavior: finding a visible modal and clicking a matching button. It could mention behavior on multiple visible modals or failure cases, but these are minor and not required for a correct call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are documented in the schema. The description adds examples of button text ('确定', '取消') but does not explain parameter semantics beyond the schema. Baseline 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it clicks a button in a visible AntD modal, naming specific modal types (Modal.confirm / Modal) and giving examples of button texts. It differentiates from generic element_click and other antd tools by scoping to modal-specific 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 provides clear context for when to use it: when a visible AntD modal contains a button to click. It implies this is the dedicated tool for modal buttons, but it does not explicitly name alternatives or state when not to use it. Thus it has clear context without exclusions.

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

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

readOnlyHint is false, consistent with the description's 'real click' indicating a mutating action. The description transparently states it performs clicks but does not mention potential side effects or failure modes, which is acceptable for a simple UI 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 that efficiently communicates the tool's purpose and the key action 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?

The tool is straightforward and the description covers the essential behavior. While no output schema is shown, this is common for UI interaction tools that return a success indicator, and the description does not need to elaborate further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all five parameters with clear descriptions, including the match type (exact) and timeout. The description does not add extra meaning beyond the schema, but the schema itself is self-explanatory and detailed.

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 operates an AntD dropdown by clicking to expand and selecting a matching option. It distinguishes itself from sibling tools like antd_get_options and antd_date_pick by focusing on the selection action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the interaction steps (real click to expand, click matching option in portal overlay) but does not explicitly contrast with alternative tools like element_select or antd_get_options. However, the context is clear enough for the intended use case.

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 indicates a destructive action (close and remove), and the destructiveHint annotation further confirms this. It also clarifies that unlike browser_connect, this tool actually exits the browser. However, it does not detail potential side effects like terminating all associated processes or closing all tabs, though the contrast helps. Since the annotation already signals destructiveness, the description adds sufficient context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of a single sentence that clearly conveys the tool's purpose and the key contrast with browser_connect. It contains 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?

For a simple browser-closing tool, the description is complete. It defines the action, contrasts with a related tool, and is sufficient for an agent to understand when and how to use it. No additional details about return values or errors are necessary for this basic operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides descriptions for both parameters (browser_id and force), covering 100% of the parameters. The tool description itself does not add additional meaning beyond the schema, 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 tool closes and removes a browser session, using the specific verb '关闭并移除' (close and remove). It also distinguishes itself from browser_connect by noting that browser_connect only disconnects without exiting, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance by contrasting with browser_connect: when you need to actually close and exit a browser session, use browser_close; when you only need to disconnect, browser_connect is appropriate. This clarifies when to choose this tool over alternatives.

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 a non-obvious behavior: the attached browser will not be exited when the service closes. This adds useful transparency beyond the readOnlyHint annotation, which indicates a non-read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two clear sentences covering the action, prerequisite, and a behavioral note. No redundant information or 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?

For a simple connection tool, the description covers the necessary prerequisites, default settings, and a key behavioral outcome. It does not mention return values or error handling, but these are not critical for a tool of this simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'address' is self-explanatory and the schema provides a default. The description mentions the default address but does not elaborate on the parameter's purpose or format, though it is implied by the context.

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 (attach to an already running browser) and includes a prerequisite (remote debugging port enabled). It distinguishes from launching a new browser by the phrase 'already running', though it does not explicitly name 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 provides the prerequisite and default address, but does not explicitly explain when to prefer this tool over alternatives like browser_launch or browser_status. The guidance is implicit rather than direct.

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?

Only mentions automatic debug port allocation; does not disclose side effects such as spawning a separate process, resource usage, or impact on existing browser sessions. The annotation only provides readOnlyHint: false, so the description adds minimal 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 a single, clear sentence with no unnecessary words. The action is front-loaded and the structure is efficient.

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 omits any mention of the return value or how the launched instance can be referenced by other tools. It also does not state that launching is a prerequisite for other browser operations, reducing completeness given the surrounding sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all five parameters, so the baseline is 3. The tool description adds no additional context or clarification about how parameters affect the launch behavior.

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 'launch' and the resource 'browser instance', with a specific detail about automatic debug port allocation. It effectively distinguishes this tool from siblings like browser_connect.

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 new instances but does not explicitly compare with browser_connect or state prerequisites. No direct guidance is given on when to prefer this tool over alternatives.

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 readOnlyHint annotation already communicates that this is a read-only operation, and the description does not contradict this. However, the description adds no additional behavioral details (e.g., side effects or performance implications) beyond the annotation.

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. There is no extraneous information, making it efficient 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?

Given the simplicity of the tool and the existence of an output schema (as noted in the context), the description provides sufficient information for an agent to understand what the tool returns. It could potentially mention that the output includes structured details, but this is not necessary because the schema covers that.

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 no parameters to describe. Since the schema coverage is trivially complete (100% coverage of zero parameters), the baseline score of 3 applies without any need for additional explanation.

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: listing all browser sessions, their tabs, and context information. It uses the verb '列出' and distinguishes this tool from more specific tools like tab_list or context_list by providing an overall status view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus alternatives. While it is a read-only status getter, the description does not mention specific scenarios or contrast with sibling tools like tab_list or context_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?

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds value by specifying that tabs and cookies are cleared, giving more concrete behavioral detail. However, it does not mention irreversibility or potential side effects on other contexts, so it is adequate but not exhaustive.

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 that conveys the core action and its effects without unnecessary words. It is appropriately concise and front-loaded with the main verb.

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 destructive action with a single parameter, the description covers the essential behavior. However, it could mention that the context must exist and that the operation is irreversible, but given the output schema exists and annotations cover destructiveness, this is a minor 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 has zero description coverage, and the description does not mention the context_id parameter. The parameter is a simple string, and its purpose is inferable from the tool name, but the description fails to explicitly connect it to the parameter, so the agent gets no extra semantic help.

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 and destroying a multi-account context, explicitly mentioning that tabs and cookies are cleared. It is specific about the resource and the effect, and it is distinct from sibling tools like context_new or cookies_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?

No guidance on when to use this tool versus alternatives. It does not mention that browser_close is for browser sessions, nor does it warn about prerequisites like an existing context. The description only states the action, not the conditions for use.

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 readOnlyHint annotation already indicates a read-only operation, and the description is consistent with that. No additional behavioral details (e.g., return format, pagination, or side effects) are provided, but the annotation covers the critical transparency requirement.

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 function. There is no superfluous information, making it highly efficient for an agent 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?

The description provides sufficient context for a simple listing operation, especially given the output schema exists (though not shown). However, it does not elaborate on the semantics of 'multi-account contexts' or the meaning of browser_id, which could be relevant for correct 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 parameter browser_id has no description in the schema or the tool description. Its purpose (e.g., filtering contexts by browser session) is not explained, leaving the agent to guess its meaning and default behavior.

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 (list) and the resource (all multi-account contexts in the browser session). This distinguishes it from sibling tools like context_new and context_close, making the tool's 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 provide any guidance on when to use this tool versus alternatives. It does not mention scenarios like enumerating contexts before selecting one, or when browser_id should be provided versus omitted.

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 states the main side effect: creating a new context with isolated cookies. It does not mention any other behavioral details such as resource usage or cleanup requirements, but given the readOnlyHint=false annotation and the straightforward creation action, the behavioral transparency 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?

The description is one concise sentence that packs the essential information: action (create), object (BrowserContext), key property (cookie isolation), and purpose (multi-account login). No superfluous 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 is complete for the tool's primary purpose, and the parameter is well documented. It does not mention the return value, but given the tool likely returns a context identifier and no output schema is provided, this is a minor gap. The description still gives an agent enough context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter browser_id is fully described: it is the browser session ID, and omitting it uses the current unique session. The schema coverage is 100% because all parameters are documented, and the description adds clarity about the default behavior.

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 creates a new isolated browser context for multi-account login. The verb '创建' (create) and the specific purpose '用于同一浏览器内登录多个账号' leave no ambiguity about the tool's function.

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 the primary use case (logging into multiple accounts in one browser) and notes cookie isolation, which signals when this tool is appropriate. It does not explicitly contrast with sibling tools like context_close or context_list, but the purpose is self-evident enough for an agent to decide when to use it.

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

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

The destructiveHint annotation already signals the destructive nature, and the description confirms it clears cookies; however, it does not disclose side effects such as clearing all cookies for the domain or affecting the current session.

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 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?

The description and schema together sufficiently cover the tool's purpose and parameter for a simple action, though the absence of an output schema leaves behavior unspecified.

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 single tab_id parameter, including its default behavior, so the description adds no additional semantic value 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 action: clearing cookies for the domain to which a tab belongs, distinguishing it from cookies_get and cookies_set.

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 conveys what the tool does but does not explicitly state when to use it versus alternatives, such as cookies_get or cookies_set.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the domain scoping constraint (current domain of the tab), which is useful context beyond annotations. However, it doesn't disclose potential behaviors like empty results or format details, which are covered by the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the purpose without any filler. It is appropriately concise for a simple read tool and front-loads the core action and scope.

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 read operation with one optional parameter. The output schema covers return format, and annotations cover safety. The only minor gap is lack of explicit mention of error cases or what happens when no cookies exist, but that's not critical for such a straightforward tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the tab_id parameter is already documented. The description doesn't add extra meaning about the parameter beyond the domain scoping, which is implied by the tool's purpose. Baseline 3 applies because the schema carries the full burden.

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 (read), the resource (cookies), and the scope (current domain of the tab). It distinguishes itself from sibling tools like cookies_set and cookies_clear by specifying the read operation, making it 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 implies usage (read cookies when you need them) but does not explicitly state when to use this tool versus alternatives or provide exclusions. Siblings are clearly different (set/clear), so it's implicitly obvious, but no explicit guidance is given.

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

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

Describes the action as writing cookies but does not mention side effects such as overwriting existing cookies, requiring permissions, or whether it merges or replaces. The annotation readOnlyHint: false aligns with the description, so no contradiction, but the description lacks depth about 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 concise and to the point, with no unnecessary information. It effectively communicates the purpose and key constraints in a single sentence.

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 essential context for using the tool: purpose, target (tab), and required cookie fields. It does not mention return values or potential errors, but the presence of an output schema reduces the need for that. The description is adequate for a simple write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds important guidance for the cookies parameter by stating each cookie must include name/value/domain. It does not elaborate on tab_id beyond the schema's own description, but the schema already covers that. Overall, it supplements the schema meaningfully.

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 it writes cookies to a tab, with the purpose of reusing login state. The verb 'write' and resource 'cookies' are specific, and it distinguishes from siblings like cookies_get and cookies_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?

Provides a clear use case ('when reusing login state') that indicates when to use this tool. It does not explicitly mention alternatives, but the context is sufficient for typical usage.

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 indicates it changes the checked state of a form control, and annotations show readOnlyHint=false, which is consistent. However, it does not mention potential side effects, errors, or whether it waits for state changes.

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 to the point, with no unnecessary words or restatements.

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 and the description covers its core action, but it lacks context about when to prefer it over similar interaction tools and what happens if the target element is not a checkbox/radio.

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 both parameters (element_id and checked), so the description adds no extra semantic value. The default behavior when checked is omitted is not explained beyond the schema default.

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's purpose: to check or uncheck a checkbox/radio button. It is specific and distinguishable from generic clicking tools like element_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?

No guidance is provided on when to use this tool instead of element_click, element_select, or other interaction tools. The agent is left to infer appropriate usage.

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?

Discloses the behavioral detail of dispatching real mouse events (move, press, release) and guaranteeing hover/focus/event chains. It also mentions the overlays in the response. The readOnlyHint=false annotation already indicates mutation, and the description adds the mechanism without contradiction.

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 three sentences covering purpose, default behavior, and output overlays. No redundant information or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core behavior and output (overlays). Given the output schema exists, it does not repeat all output fields, but mentions the important overlay aspect. It is sufficiently complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All four parameters are described with 100% coverage. Each description explains the purpose clearly: element_id from find_element, by_js for obscured elements, observe for overlays, and use_action for choosing between Actions and simulated clicks. Default values are indicated.

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 as clicking an element, with a specific verb 'click' and resource 'element'. It distinguishes from sibling hover and other element operations by mentioning the default real mouse event dispatch, making the intent 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?

Provides usage guidance by explaining the default method (Actions) and the optional by_js for obscured elements. However, it does not explicitly contrast with hover or other click-like siblings, though the conditions for using by_js are 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?

It discloses that the tool triggers hover effects and popups, which is the primary behavioral outcome. It does not mention potential side effects, but none are critical for a hover 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 concise sentence that delivers the core information without verbosity or irrelevant details.

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 sufficiently complete for a hover action with one parameter. It does not mention output or return values, but for a simple UI action this is not 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 single parameter element_id is not explained in the description, and the schema provides no additional description. The parameter name is somewhat self-explanatory but the description adds no value to 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 action (hover) and its purpose (trigger hover effects, tooltips). It is specific to the element_hover tool and distinguishes it from sibling tools like element_click or element_input.

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 hover effects are needed but does not explicitly state when to use or not use this tool compared to alternatives. It lacks explicit when/when-not 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 readOnlyHint annotation already signals no side effects, and the description's 'get' wording reinforces this. The description does not go beyond the annotation, but it does clearly indicate the read-only nature without contradiction.

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 lists the types of information returned without unnecessary detail. It is well-structured and directly conveys the tool's function.

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 enumerates the categories of data returned (text, HTML, attributes, value, link, position/size, state), which gives a good overview. However, it does not specify the output format or structure, though the existence of an output schema is indicated. For a simple read tool, this is nearly 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 no description for element_id, and the tool description does not explain its meaning, format, or how to obtain it. The parameter name is self-explanatory to some extent, but the lack of additional context means the description does not compensate for the schema's sparse documentation.

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 retrieve comprehensive element information including text, HTML, attributes, value, link, position/size, and state. The verb '获取' (get) and resource '元素' (element) precisely define the action, and the tool is distinct from sibling tools that perform actions like clicking or hovering.

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?

While the description implies that this tool is used to inspect element properties, it does not explicitly contrast it with sibling tools like find_element or get_page_info. No explicit guidance is provided on when to use this tool over alternatives, leaving some ambiguity.

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 indicates a write operation (input text), and the readOnlyHint=false annotation is consistent. It does not disclose potential side effects like triggering events or clearing existing text, but the 'clear' parameter is available. Overall, the behavior is transparent enough given the simple 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, concise sentence without any redundant information. It is well-structured and directly states the tool's function.

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 input action, the description and schema provide all necessary information to invoke the tool correctly. There are no missing details about preconditions, return values, or side effects that would hinder an 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 clear descriptions for all four parameters (element_id, text, by_js, clear), achieving 100% coverage. The description adds no extra detail beyond the schema, so it meets the baseline but does not enhance understanding further.

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 input text into an input box element. This is a specific verb-resource combination that distinguishes it from sibling tools like element_click, element_hover, and element_select.

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 explicit guidance on when to use this tool versus alternatives, such as element_click or element_select. However, the name and description imply usage for entering text into input fields, which is clear enough for an agent to infer.

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 side effects or behavior beyond the basic action. With only readOnlyHint=false in annotations, the description carries full responsibility, but it fails to mention whether scrolling waits for the scroll to complete, whether it affects other browser state, or if it throws errors on invalid actions.

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 with no redundant information. It is well-structured and easy to parse, though it could be slightly more informative about behavior.

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 scroll action, the description is adequate but not fully complete. It lacks context on when to use it, what the output is (though an output schema exists), and any edge cases or side effects. This leaves some ambiguity for an 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 includes descriptions for all parameters: element_id, pixel, and action with enum-like values. The tool description adds no additional meaning beyond what the schema provides, so it meets the baseline for complete 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 scrolls an element or scrolls it into view, which distinguishes it from other scroll-related tools like vtable_scroll_viewport. However, it does not explicitly mention the action parameter's options in the tool description, though the schema covers 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 provides no guidance on when to use this tool versus alternatives such as vtable_scroll_viewport or vtable_scroll_to_cell. It does not explain scenarios where pixel scrolling vs scroll-into-view is preferred, leaving the agent to infer usage.

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 behavioral details beyond the annotation readOnlyHint=false, such as whether the action triggers change events, requires element visibility, or how it handles invalid options. It adds minimal transparency beyond the annotation itself.

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 purpose without unnecessary words or redundancy. It is well-structured and directly 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 schema fully describes all parameters and an output schema is present, the description is sufficiently complete for a simple select operation. It does not explain error cases, but such details are not essential for this level of simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all three parameters with descriptions (by, value, element_id). The tool description adds no additional meaning beyond what the parameter descriptions already provide, 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: 'Select an option in the dropdown box (<select>) element.' It is a specific verb+resource combination that distinguishes it from sibling tools like antd_select and vtable_click_cell.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given on when to use this tool over alternatives. It does not mention that it targets native HTML <select> elements or contrast it with antd_select for Ant Design components, leaving the agent to 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?

Annotations include readOnlyHint: true, and the description mentions only locating and returning data, with no contradictory side effects. It does not add extra behavioral details beyond the annotation, but is consistent.

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 leads with the action (locate an element) and clearly states the return value, with no 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?

The description indicates the return value (summary and element_id) and there is an output schema present, so the description is adequate for calling the tool correctly. It does not explain the summary content, but the output schema likely covers 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?

All parameters have schema descriptions covering 100% of the parameters, providing detailed syntax for locator and other options. The description itself adds no additional parameter information, so baseline 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?

States the tool locates an element in a tab and returns a summary and element_id, clearly distinguishing it from find_elements (plural) and wait_element.

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?

Does not explicitly mention when to use this tool versus alternatives like wait_element or find_elements, though it implies use for subsequent interaction tools. The description provides some context but lacks explicit 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 readOnlyHint annotation covers the read-only nature. The description adds the detail of returning a summary list but does not elaborate on waiting behavior, timeout handling, or what occurs when no elements are found, which are relevant behavioral aspects.

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 wording. It conveys the essential functionality and output format efficiently.

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 adequate for a simple read-only tool: it states what it does and what it returns. Minor omissions like error handling or relationship to sibling tools are not critical for basic invocation, but a bit more context could improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all five parameters, achieving 100% coverage. The tool description itself does not add extra meaning to the parameters, so it meets the baseline without enhancement.

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 purpose: locating all matching elements in the tab and returning a summary list with element_ids. It distinguishes from the singular find_element by explicitly saying 'all matching elements'.

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 any explicit guidance on when to use this tool versus alternatives like find_element or other navigation tools. It only describes the action without contextual selection 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 transparently discloses the scope (top-level DOM) and the nature of the output (iframes with visibility status, where visible means active functional module). It aligns with the readOnlyHint annotation, indicating a read-only operation with no side effects. Minor ambiguities like the exact definition of 'visible' are present 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 concise and to the point, covering all necessary information in two sentences without any redundant or verbose language. It efficiently communicates the tool's function and the relevance of its output.

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 provides sufficient context for an agent to understand the tool's role, including the output's relationship to other tools. While it does not explicitly discuss error handling or edge cases, the presence of an output schema and the straightforward nature of the operation make the description adequate for correct 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 two parameters (tab_id and browser_id) have no descriptions in the schema or in the tool description. They appear to be optional identifiers, but their exact meaning and expected values are left unexplained. With 0% schema coverage and no textual explanation, the agent has to infer their purpose, which is insufficient for effective invocation.

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: listing all iframes in the tab's top-level DOM along with their visibility status. It also explains that the returned frame_index/iframe_id can be used as the frame parameter for other tools, making its role unambiguous and distinct from sibling tools that operate on elements or navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by stating that the returned frame identifiers can be used as the frame parameter for other tools, which is a clear practical use case. However, it does not explicitly mention when to use this tool versus alternatives or provide conditions for its use, though this is not critical given its unique function.

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 annotation readOnlyHint=true already indicates safety. The description adds beneficial behavioral details: it excludes iframe content and truncates if exceeding max_chars, making side effects and output limits transparent. No contradictions.

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 unnecessary words. It directly states the action, the scope (excluding iframes), and the truncation rule. Perfectly 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?

The description provides sufficient context for an agent to understand the return value (HTML string) and its limitations. No output schema is present, but the description covers the essential behavior. Minor missing details like error handling are not critical.

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?

Both parameters (tab_id and max_chars) have complete schema descriptions explaining their meaning and defaults. The description does not add extra semantic information beyond what the schema already provides, so the baseline 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 clearly states the tool's purpose: to get the complete HTML of the current tab page, excluding iframe inner content, with truncation behavior. This is specific and distinct from sibling tools like get_page_info or run_js.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention when not to use it or compare it to other HTML-retrieval methods (e.g., run_js). The agent must infer 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?

The readOnlyHint annotation is present and the description does not contradict it. However, the description adds no extra behavioral details such as error handling or behavior with invalid tab IDs, beyond what the annotation implies.

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 that efficiently communicates the tool's function without unnecessary words or complex structure.

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 lists the specific output fields (URL, title, status, user agent), providing sufficient context for a simple read operation. It lacks details on return format or error conditions, but these are not critical given the simplicity of the 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 only parameter tab_id is optional with default null, but the description does not explain its meaning or the effect of omitting it (e.g., whether it refers to the active tab). Schema coverage is 0%, leaving the parameter entirely unexplained.

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 fetches the current URL, title, loading status, and user agent of a tab, which is specific and distinct from sibling tools like tab_info or vtable_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use it (when page-level metadata is needed) by listing the exact information returned, but does not explicitly state when not to use it or compare with alternatives.

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 readOnlyHint annotation already indicates no side effects, and the description reinforces this by stating it only reads content. It also transparently explains the default scope (main document + auto-penetrating iframes) and the portal attachment behavior, ensuring no surprises.

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 and to the point, covering the purpose, usage context, and frame behavior without any redundant information. It is well-structured 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?

The tool has an output schema, and the description provides essential usage context (asserting operation results) and handling of iframe/portal specifics. It is complete for an agent to decide when and how to invoke it, especially given the related tool environment.

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?

Both parameters (frame and tab_id) have clear descriptions. 'frame' explains the meaning of 'active' and references frame_list for valid values; 'tab_id' specifies the default behavior when omitted. The schema coverage is 100%, and the descriptions add necessary context.

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 reads current AntD message and notification content for assertion purposes. It is distinct from sibling tools, which focus on navigation, element interaction, or other AntD-specific actions, 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?

It explains when to use the tool ('用于操作结果断言' – for asserting operation results) and provides specific guidance on frame selection due to portal behavior, advising to use frame='active' or the triggering element's frame. This gives actionable context beyond the basic function.

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 states the basic behavior (opens a URL and returns a result) and mentions that it operates 'in a tab' (implying it may navigate an existing tab). The annotation readOnlyHint=false already signals that this is a mutating action, so the description does not need to over-exploit that. However, it does not disclose potential side effects such as navigating away from the current page or losing unsaved state, and it does not explain output details beyond the return fields. The param descriptions give some behavior (tab_id, timeout), but the main description does not go beyond the core action. This is adequate but not particularly 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 a single, concise sentence that immediately states the core function and the expected return structure. It is front-loaded with the verb and object, and there is no unnecessary wording. It perfectly fits the desired compactness for a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively straightforward navigation tool, the description is complete enough: it explains what it does, what it returns, and the key parameters are well-described in the schema. It does not cover edge cases like navigation failures or timeouts beyond the default, but those are minor and the tool is simple. The lack of explicit guidance on when to use it vs. siblings is covered under usage_guidelines, not here. The description adequately covers its context for an agent to invoke it correctly in most 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 input schema provides full descriptions for all three parameters (url, tab_id, timeout) with 100% coverage. The description text itself does not add any additional meaning or elaboration about the parameters, such as constraints, dependencies, or examples. Since schema coverage is high, the baseline is 3. The parameter descriptions are clear and functional, but the tool description adds no extra value beyond them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: '在标签页中打开网址，返回导航结果（url/status/ok）' (open a URL in a tab, return navigation result). It specifies the action (open URL) and the resource (URL). However, it does not explicitly distinguish itself from sibling tools like tab_new (for creating a new tab) or refresh, though the tool name 'navigate' and title '打开网址' make the purpose unambiguous. A 5 would require explicit distinction from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool instead of other navigation-related siblings such as navigate_back, navigate_forward, refresh, or tab_new. It does not state any conditions, alternatives, or exclusions. The only implied usage is 'open a URL', which is inherent to the action itself, but not an explicit guideline. A score of 3 would require some implied usage context; here there is none beyond the literal 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?

The description discloses the basic behavior (browser back) but does not mention any side effects, edge cases (e.g., exceeding history length), or error handling. The annotation readOnlyHint=false is consistent with the action's state-changing nature, and no contradiction exists. However, richer detail on behavior 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 exactly conveys the tool's function without any unnecessary words or repetition. It is well-structured 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?

Given the simplicity of the tool and the presence of an output schema (not shown but indicated by 'Has output schema: true'), the description is complete. It does not need to explain return values, and all essential information for using the tool is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no extra meaning beyond the schema. The schema already provides Chinese descriptions for both 'steps' and 'tab_id' (e.g., '后退步数' and '标签页 id，省略时用最新标签页'). Since schema coverage is 100%, 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 action: '在标签页中执行浏览器后退' (execute browser back in the tab). The tool name 'navigate_back' is unambiguous, and the action is simple and specific, leaving no room for misinterpretation.

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 only a direct action statement without explicitly contrasting with sibling tools like 'navigate_forward' or 'navigate'. While the purpose is clear, the description does not guide on when to prefer this tool over alternatives, though the simplicity may not require extensive 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 annotation readOnlyHint: false already indicates it's not read-only. The description adds no information about side effects like loading a page, potential errors if history is empty, or interaction with tab_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with 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?

The description omits edge cases such as behavior when there is no forward history or when tab_id is invalid. However, for a simple navigation action, it provides the core functionality.

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?

Both parameters have descriptions in the schema (steps and tab_id), providing adequate meaning. The tool description doesn't add extra clarification, but schema coverage is 100%.

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: 'execute browser forward' in the tab. This distinguishes it from sibling navigation tools like navigate_back or navigate.

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 such as navigate_back or refresh. The description is purely a statement of functionality without 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?

Beyond the readOnlyHint annotation, the description discloses concrete behavioral details: it returns up to 40 controls and truncates text to 24 characters. This extra context helps the agent understand what to expect from the return value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences that front-load the purpose and then provide usage context. It avoids unnecessary detail and is 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?

Given that an output schema is present, the description does not need to explain return values. It sufficiently covers purpose, usage, and behavioral constraints, making it complete for the tool's scope.

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 descriptions already cover both parameters (frame and tab_id) with comprehensive explanations of defaults and allowed values. The tool description itself does not add any additional meaning to the parameters, so it stays at 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 that the tool lists interactive controls on the current page (buttons, inputs, dropdowns, links) with a limit of 40 items and text truncation at 24 characters. It also distinguishes this from precise interaction tools like find_element and element_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 explicitly states when to use it: 'for first entering a page to quickly grasp available operations' and then suggests using find_element + element_click for precise interaction afterwards. This provides clear guidance on the intended workflow.

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 phrase 'real keyboard event' discloses that the action is a genuine OS-level keypress, which is a behavioral detail beyond the readOnlyHint=false annotation. It does not mention focus requirements or potential side effects, but the annotation already signals a mutation.

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 wording. It includes both the action and examples, making it highly readable.

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 key-press operation. It does not mention the output, but an output schema is present separately. The brief scope fits the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes both parameters (key and tab_id) with clear descriptions, so the tool description adds no extra semantic value. 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 presses and releases a keyboard key, with examples of specific keys. This distinguishes it from mouse-based or element-specific actions like element_click or element_input.

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 sending keyboard events (e.g., Enter, Esc, arrow keys) but does not explicitly contrast with alternatives like element_input or action_chain. The examples help, but explicit guidance on when to choose this over other input methods is missing.

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 implies a state change (refresh) and the annotation readOnlyHint=false confirms this, but it does not disclose potential side effects like reloading resources or losing unsaved input. The behavior is simple and generally understood, but 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 a single, short sentence that perfectly captures the tool's function without any fluff or unnecessary detail. It is optimally concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple refresh action, the description is sufficient to understand the core operation. However, it does not mention potential edge cases like tab not found or whether it waits for page load, which could be relevant in complex workflows but are not critical for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description itself adds no parameter details, but the schema already provides full descriptions for tab_id (including null meaning) and ignore_cache. Since the schema carries the semantic weight, the description does not need to repeat it, yet it also does not add extra insight.

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') and the target ('current page of the tab'), leaving no ambiguity about the tool's purpose. It is concise and directly conveys the intended 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 provides no guidance on when to use this tool versus alternatives such as navigate or wait_element. It does not mention expected scenarios or prerequisites, leaving the agent to infer usage context from the tool 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?

Annotations indicate readOnlyHint=false, so the agent knows this may have side effects. The description adds the behavioral detail that only JSON-serializable results are returned, which is useful. However, it does not disclose potential side effects beyond that, such as whether the script can navigate the page or modify state. Given the annotation already flags non-read-only, the description adds a bit of value but leaves room for more 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 a single, front-loaded sentence that immediately states the action and result. No redundant phrasing or filler. It earns its place by being short and direct.

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 has an output schema, so return format is covered elsewhere. The schema fully documents all parameters. The description explains the core purpose and the JSON-serializable constraint. The main missing piece is usage guidance (e.g., when to prefer this over other tools), but for a simple execution tool with annotations and schema, the description 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?

Schema description coverage is 100%, so the parameters (script, tab_id, as_expr) are fully documented in the schema. The description does not add additional meaning beyond what the schema provides. It only clarifies the return value, not the parameters, 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 clearly states the tool executes JavaScript in a tab and returns the JSON-serializable portion of the result. This is a specific verb (execute) + resource (JS in tab) + outcome (return result). It distinguishes itself from all sibling tools since none other directly executes arbitrary JS.

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 any preconditions (e.g., needing a live tab), nor does it suggest when custom JS is preferable over higher-level element actions like element_click. The as_expr parameter is explained in the schema, but not in terms of use-case 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?

Beyond the destructiveHint annotation, the description explicitly details edge cases and destructive behavior (closing tabs, including all others), providing full transparency about the tool's 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 a single, concise sentence that covers the core function and all relevant variations without unnecessary detail 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?

Given the simplicity of the tool and the full parameter descriptions in the schema, the description is sufficient for an agent to correctly invoke and understand the tool's behavior 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 input schema already includes complete descriptions for both parameters (others and tab_id). The tool description essentially repeats this information without adding new semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool closes a tab, with specific behavior for omitted tab_id and the others flag. It is unambiguous and distinctive among tab-related 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 the behavior conditions (closing latest tab when tab_id omitted, closing all others when others=True) but does not explicitly compare to alternative tab tools. Still, the usage context is clear enough.

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

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

The readOnlyHint annotation already indicates this is a read-only operation. The description does not add any additional behavioral details or side effects, but it does not contradict the annotation either.

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 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 simple getter, the description covers the core functionality. However, it does not mention the output schema or any edge cases (e.g., behavior when no tab_id is provided), which could be relevant for an agent but is not strictly required.

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 two parameters, tab_id and browser_id, are not described at all. The schema provides no descriptions, and the tool description does not explain what these identifiers refer to or how they should be used. This leaves the agent without critical 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?

Description clearly states the tool retrieves the current URL, title, and loading status of a tab, using the verb '获取' (get) with a specific resource. It is distinct from sibling tools like tab_new or tab_close, and its purpose 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?

The description provides no guidance on when to use this tool versus alternatives such as get_page_info or browser_status. It does not mention any specific conditions or use cases beyond the basic function.

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?

注解已声明 readOnlyHint=true，描述未添加额外行为信息，如返回格式、排序规则或可能的影响。由于注解已覆盖只读性，描述未进一步披露任何超出注解的细节。

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?

工具简单，仅有单个可选参数，且有输出模式，基本信息足够。但缺少使用场景和参数说明，整体略不完整。

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?

模式中定义了可选参数 browser_id，但描述未解释其用途。由于 schema 覆盖率为0%，描述本应补偿参数语义，但完全未提及，仅依赖参数名推测。

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?

描述明确指出动词“列出”和资源“所有标签页”，目的清晰。虽然未明确区分于其他标签页工具，但功能本身明确，且与 tab_info 等单个标签页工具有明显区别。

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?

描述仅说明功能，未提供何时使用、何时不使用或替代工具的建议。虽然用途隐含，但缺少明确的场景说明和与其他工具（如 tab_info）的选择依据。

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 indicates the mutating action (creating a tab) and the cookies-isolation effect, but does not disclose whether the tab receives focus, what it returns, or possible errors. readOnlyHint=false is consistent.

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 brief and every sentence contributes useful information; there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation action, it covers the key contextual distinction (multi-account isolation). However, it does not mention return values or focus behavior, though an output schema is reportedly present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and descriptions already explain all parameters; the tool description only adds context_id behavior, so it adds no significant parameter meaning 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 creates a new tab and specifies the context_id behavior, but it does not explicitly distinguish it from related tab operations beyond the name.

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 explains the main conditional behavior (context_id for multi-account isolation) but gives no explicit guidance on when to choose this tool over siblings like navigate or tab_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?

The description adds a behavioral detail beyond the readOnlyHint annotation by mentioning the coordinate calculation (换算出页面视口绝对中心点坐标). It is consistent with readOnlyHint (读取) and does not contradict annotations. However, it does not elaborate on potential side effects or limitations, so it is not a perfect 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 a single, compact sentence that packs the purpose and a practical usage note without any redundant fluff. It is well structured and easy to parse, achieving high information density with minimal 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?

Given the tool has an output schema (not shown), the description gives a useful high-level summary of the return content (value, type, geometry, and coordinates) without specifying the exact structure. It covers the main purpose and a practical application, but omits details like error cases or return format specifics, which are partially mitigated by the existence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 4 parameters (col, row, tab_id, table_index) with 0% description coverage, and the description provides no information about any of them. Since schema coverage is low, the description should compensate by explaining the parameters, but it is entirely silent on this, leaving users to infer meanings from bare names.

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 reads cell value/type/geometry information and calculates the absolute center point coordinates for the viewport, which is a specific and unambiguous purpose. It also ties the output to a concrete use case (action_chain move_to), making the intent highly understandable.

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 a usage hint by noting the coordinate can be directly used for action_chain's move_to, but it does not explicitly compare against sibling tools or state when to prefer this tool over alternatives like vtable_resolve_cell or vtable_find_cell. It gives a usage context, not a selection guideline.

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 readOnlyHint annotation already indicates read-only behavior, and the description adds specific details about what state is read (selection, checkbox state, visual signature). It does not mention potential side effects (though none expected) or error conditions, but the added detail goes beyond the annotation.

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, reasonably concise sentence that states the tool's purpose and gives an example use case. It avoids excessive verbosity while still conveying key information about the returned data.

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 a sense of what is returned (selection, checkbox state, visual signature) but does not detail the output structure. Since an output schema exists (per context), the description could be more specific about the shape of the result, especially the 'scenegraph visual signature' field.

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 has 4 parameters (col, row, tab_id, table_index) with zero coverage from the description. Even though col and row are somewhat self-explanatory, tab_id and table_index are ambiguous in the vtable context and are not explained. The description provides no parameter guidance.

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 this tool reads cell state, including selection, checkbox/radio/switch values, and visual styling (fill/stroke). It distinguishes itself from sibling tools like vtable_cell_text and vtable_cell_info by focusing on state and visual signature rather than text or general info.

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 includes a usage hint (compare before/after operations to assert highlight/color changes) but does not explicitly specify when to prefer this over related tools like vtable_get_selection or vtable_cell_info. The guidance is implied rather than direct.

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 internal behavioral logic beyond the readOnlyHint annotation: it specifies the priority order of text sources (scenegraph first, then fallbacks) and states that it annotates the source of the hit. This is detailed and transparent, covering what the agent needs to understand about the tool's operation without contradicting the annotation.

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 dense, single paragraph that front-loads the core function ('深度提取单元格的显示文本'), then efficiently explains the fallback chain and the usage note. Every sentence adds substantive value with no repetition or fluff, making it well-structured and concise.

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 thoroughly covers the extraction logic and the key usage scenario. Since an output schema exists, the return structure is not expected to be repeated. However, the lack of parameter guidance is a notable gap, especially given zero schema coverage. Minor edge cases (e.g., all fallbacks failing) are not addressed, but overall the description is complete for a read-only 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?

Schema description coverage is 0%, and the description provides no additional meaning for the four parameters (col, row, tab_id, table_index). It does not clarify indexing conventions (0- vs 1-based), when optional parameters are required, or any formatting details. The parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation.

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 core function: deep extraction of a cell's display text. It specifies the resource (cell in a vtable) and the action (extract display text), and details the fallback priority chain (scenegraph rendered text, overflow full text, display value, raw value, business record field). It also explicitly positions this tool as the authoritative source when getCellValue disagrees with the page, distinguishing it from simpler cell read 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 provides a clear usage condition: 'When getCellValue and page display are inconsistent, use this as the authority.' This tells the agent when to prefer this tool. However, it does not name specific sibling alternatives or explicitly state when not to use it, leaving some inference to the agent.

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?

Annotations only declare readOnlyHint=false. The description adds valuable behavioral context: it performs a real mouse click via action_chain, triggers full hover/focus/selection behaviors, and auto-scrolls into view. This goes beyond the annotation and helps the agent anticipate 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 a single, front-loaded sentence that states the action and key behavioral details without redundancy. Every phrase adds value, making it 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?

The tool has an output schema (not shown) and annotations cover the read-only flag. The description explains the click mechanism and auto-scroll behavior. It does not mention prerequisites like an active table context or tab, but given the sibling suite and typical usage, it is largely complete for a click 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?

Schema description coverage is only 43%, and the description does not add explanations for the undocumented parameters (col, row, tab_id, table_index). It mentions auto-scrolling, which relates to positioning, but does not clarify parameter formats or constraints. Since the schema does not document most parameters and the description does not compensate, this is a significant gap.

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: clicking a VTable cell, with specifics on auto-scrolling and real mouse events. It distinguishes itself from sibling tools like vtable_hover_cell and vtable_click_icon by emphasizing real mouse movement and full hover/focus/selection behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool—when you need genuine mouse click behavior on a VTable cell rather than synthetic JS events. It does not explicitly name alternatives or exclusion conditions, but the context of siblings and the real-click emphasis provide adequate 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?

Beyond the annotation readOnlyHint: false (write action), the description adds that icons are discovered via VTable scenegraph and clicked with real mouse at viewport-absolute coordinates. However, it does not disclose potential side effects (e.g., triggering sort/filter toggles) or whether it waits for resulting UI changes. Some transparency is present but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise and front-loaded with the action. It lists examples and explains the mechanism without extraneous detail. Every sentence 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 description conveys what the tool does and how icons are located, but omits information about return values (despite having an output schema), error handling, or post-click behavior. It is sufficient for a basic understanding but lacks completeness for a tool that can trigger dynamic UI changes.

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 only 33% (name and index have descriptions; col, row, tab_id, table_index do not). The description does not compensate by explaining what col and row refer to (e.g., zero-based cell coordinates) or the roles of tab_id and table_index. Although the scenegraph mention hints at coordinate usage, it leaves critical parameters underdocumented.

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 (click interactive icons) and the target (icons inside cells/headers), with concrete examples like sort arrows, filter funnels, checkboxes, and expand/collapse. It distinguishes itself from sibling tool vtable_click_cell by explicitly focusing on icons rather than cell bodies.

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 needing to interact with icons, but does not explicitly mention when not to use it or compare with alternatives like vtable_click_cell. There is no exclusion of cases (e.g., 'prefer this over clicking the cell body'), so guidance is merely implied rather than 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?

The description mentions the use of real mouse events (按下→拖动→释放) and notes that scrollbar geometry is computed deterministically because it's canvas-drawn. It also states it returns before/after scrollTop/scrollLeft. However, it does not mention potential side effects, prerequisites, or failure modes, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences—with no redundant information. Every clause adds value, covering the action, mechanism, and return value without extra fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, some with unclear semantics), the description is incomplete. It doesn't explain the role of tab_id/table_index, the conditions for successful execution (e.g., scrollbar visibility), or the exact structure of the return value beyond scrollTop/scrollLeft. This leaves the agent guessing about important details.

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?

Only two of four parameters (direction and distance_px) have descriptions, with distance_px explaining the multiplication by content ratio. The tab_id and table_index parameters have no description at all, leaving their purpose and default behavior ambiguous.

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 (drag scrollbar) and the resource (VTable), with enough specificity to distinguish from sibling tools like vtable_scroll_viewport or vtable_scroll_to_cell. Mentioning 'canvas 绘制' further clarifies the target is the table's built-in scrollbar.

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 (for real mouse drag on the scrollbar), but does not explicitly contrast with alternatives like programmatic scrolling or scroll-to-cell. A user must infer the use case from the description alone, which is adequate but not 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?

描述说明了编辑会落值，commit=false 保持编辑态；但未提及其他副作用（如覆盖原值、触发事件、校验失败行为），在仅有 readOnlyHint=false 的情况下仍有少量信息缺口。

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?

在兄弟工具较多的上下文中，足以区分 vtable_edit_cell 与其他 VTable 操作，并给出替代方案；但缺少坐标体系和 tab_id/table_index 的定位说明，未达到完全完整。

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 覆盖率仅 33%，描述只补充了 value 和 commit 的含义；col/row 未说明是否从 0 开始或针对哪个表格，tab_id/table_index 也完全未解释，参数语义不充分。

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?

明确描述通过 VTable editor 编辑单元格并落值，使用具体动词和资源；同时区分 API 级编辑与真实键入流程，能够与 vtable_click_cell 等兄弟工具区分。

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?

说明前置条件（列配置了编辑器），并明确指出如需真实键入流程应改用 vtable_click_cell(double_click=True) + action_chain + press_key，给出了清晰的 when 和 when-not。

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 annotation readOnlyHint is present, so the read-only nature is covered. The description adds the detail that the search includes headers, but does not disclose any other behavioral aspects such as performance implications or result limits.

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 clearly states the purpose. It is front-loaded with the action and resource, with no unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a simple read-only search function. It mentions the return structure and the scope (entire table including headers). The output schema exists, so additional details are not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 100% of the parameters, so the baseline is 3. The tool description does not add any additional parameter-specific semantics 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: searching for cells by text in the entire VTable including headers, and returning a list of {col, row, value}. This is a specific verb and resource, distinguishing it from other VTable operations.

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 text search but does not explicitly compare with sibling tools or state when to prefer this over other VTable functions. It provides no alternative guidance.

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