DrissionPage-MCP

by hooplus1ce

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a very distinct purpose, even within the large VTable group where tools target different actions like reading, finding, clicking, editing, and hovering. There is minimal functional overlap that would confuse an agent.
Naming Consistency2/5
Naming conventions are mixed: some tools use verb-first patterns (get_page_html, find_element), while many use object-first patterns (browser_launch, cookies_get, vtable_read_cells). This inconsistency, though readable, fails to follow a single predictable scheme.
Tool Count1/5
With 56 tools, the server vastly exceeds the typical range. Even for a specialized VTable browser automation server, many tools could be consolidated (e.g., cell_info, cell_text, cell_state), making the surface area unwieldy.
Completeness5/5
The toolset comprehensively covers browser lifecycle, navigation, tab management, element interactions, iframes, cookies, multi-account contexts, and an exceptionally deep set of VTable-specific operations including selection, scrolling, editing, and visual state inspection.
Average 3.8/5 across 56 of 56 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation is consistent with the described scroll behavior; no mutation or destructive side effect is implied. The description directly communicates the tool's visible effect, which is appropriate for a read-only viewport adjustment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It states the primary action and an important supporting detail about virtual scrolling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are not mandatory. However, the description lacks parameter-level context and does not distinguish when to use this tool versus related vtable scrolling tools, leaving only moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of col, row, tab_id, or table_index. The agent must infer coordinate semantics and optional targeting behavior without any supporting detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scroll') and the resource ('VTable' to a specified cell), with the goal of bringing that cell into the visible area. It does not explicitly name the sibling tool vtable_scroll_viewport, but the cell-specific target distinguishes it well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over vtable_scroll_viewport or other vtable navigation tools. The description mentions virtual scrolling support but does not explain practical use cases or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action (wait for element) and does not describe timeout behavior, what happens on failure, or whether it returns immediately after appearance. The annotation readOnlyHint covers the read-only nature, but the description adds no extra behavioral context such as blocking or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the core purpose. It is well-structured and front-loaded with the primary function, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple waiting operation, the description is adequate. It states the action and the context (page load/AJAX). The output schema and annotations fill in the return details, so the description is sufficiently complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all four parameters (frame, tab_id, locator, timeout) with 100% coverage. The tool description itself does not elaborate on these, but since the schema already provides sufficient semantic detail, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'wait for element to appear' (等待元素出现). It also provides context about when this occurs (page load, AJAX render). However, it does not explicitly differentiate from find_element, which might also be used to locate elements, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 conditions like 'when you need to ensure an element is present before interacting' or contrast with find_element. The name and description imply waiting, but explicit usage instructions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details: it uses a 'real mouse' hover and 'auto-scrolls' into view. This goes beyond the readOnlyHint annotation by explaining the action mechanism. However, it does not mention potential side effects like moving the mouse pointer or triggering hover effects, though readOnlyHint covers the main safety aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but dense and free of fluff. It is well-structured and directly mentions the key facts. It could benefit from a bullet list for the output items, but overall it is concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's purpose and behavior are described, but critical context is missing: coordinate system (0-based vs 1-based), expected return format, and behavior when the cell is not found. Since an output schema exists, the return format may be covered there, but the description alone leaves some gaps for a tool that requires precise cell coordinates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage, and the description does not explain col, row, tab_id, or table_index. It mentions 'cell' and 'same-row neighbor' but never specifies coordinate systems, indexing, or the meaning of the optional parameters. Since the schema provides no help, the description fails to compensate, leaving the agent with insufficient parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: real mouse hover on a cell (with auto-scroll) to read hover-state color information. It lists specific outputs (background color, text color, interactive text status, row highlighting) and distinguishes itself from sibling tools like vtable_read_cells or vtable_cell_info by focusing on hover states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly indicate when to use it over alternatives. There is no mention of 'use this when you need hover colors' or 'instead of vtable_cell_info'. The purpose is clear but the selection guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description aligns by describing a mutation (dispatching a wheel event). It adds the sign convention for delta_y and delta_x, and specifies that the event is a 'real' mouse wheel event. However, it does not disclose potential side effects like triggering other handlers or behavior at scroll boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the key action, and efficiently explains the delta sign conventions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is relatively simple, the description does not explain the tab_id and table_index parameters, does not mention any prerequisites or side effects, and does not differentiate from sibling scroll tools. The output schema exists but its content is unknown, so it's unclear if return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the meaning of delta_x and delta_y by specifying the sign convention and that they are pixel approximations, complementing the schema descriptions. However, tab_id and table_index are not explained in the description or schema, leaving their semantics ambiguous; schema description coverage is only 50%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it dispatches a real mouse wheel event to the center of the VTable canvas, with sign conventions for delta_x and delta_y, and its purpose for manually adjusting the visible window. This clearly differentiates it from siblings like vtable_scroll_to_cell and vtable_drag_scrollbar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is '用于手动调整可视窗口' (for manually adjusting the visible window), which implies a use case, but it does not provide explicit guidance on when to choose this over other scroll tools such as vtable_scroll_to_cell or vtable_drag_scrollbar, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is reinforced by the description's read action and no side effects. It adds transparency by naming the official data source getSelectedCellInfos and the intended assertion use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no fluff, front-loading the action and then providing useful output/usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, output fields, and intended usage, but omits any explanation of the optional parameters tab_id and table_index, which an agent may need to target the correct VTable instance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The two parameters tab_id and table_index have no schema descriptions and are not mentioned in the tool description. With 0% schema description coverage, the description fails to compensate by explaining what these parameters identify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (read current selection details) and resource (VTable current selection), and includes output fields. It clearly distinguishes from sibling VTable tools by focusing on the active selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it after clicking or box-selecting cells for assertions, giving a clear usage moment. It does not name alternative tools or negative conditions, but the selection scope implies when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the content of the returned list (columns with specific attributes), adding context beyond the readOnlyHint annotation, but doesn't mention error behavior or side effects (though it's read-only, so that's implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information, clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The purpose and output content are covered, and output schema exists, but the parameters are left unexplained, leaving the agent to guess their meaning in the VTable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters tab_id and table_index at all; schema lacks descriptions, so the agent has no guidance on what these mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly it lists all columns of a VTable and specifies the fields returned (col index, field, title, cell type) and the typical use case (mapping business column names to col index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific use case ('用于把业务列名映射为 col 序号') but does not explicitly contrast with sibling tools or give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only; the description adds useful constraints (max 2000 cells, row-major order) and confirms no side effects. This provides additional behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence with no redundancy. It captures the core purpose and key constraints efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, scope (region), limit, and data structure. Does not detail every parameter, but given the output schema exists and common VTable context, it is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema lacks parameter descriptions; the description clarifies that col0/row0 and col1/row1 define a rectangular region and mentions row-major order, but does not explain tab_id/table_index. Partial compensation for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads cell values from a rectangular region of a VTable, specifying row-major matrix and a maximum of 2000 cells. This distinguishes it from single-cell reads like vtable_cell_text or vtable_get_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch reading but does not explicitly compare with sibling tools or state when to prefer this over alternatives. An agent can infer based on the action, but there's no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint 已说明只读属性，描述中“解析”“直接走内部映射 API”也表明无副作用；未描述可能的失败/边界行为，但低风险只读操作下已有足够透明度。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
在已有输出 schema 的情况下无需解释返回值；但未说明多表/多 tab 场景下如何通过 tab_id/table_index 消歧，且未提及与 vtable_headers/read_cells 的协作方式，完整性有缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
必填参数 field 和 record_index 有明确说明（含 record_index 从 0 起、不含表头）；但可选参数 tab_id 和 table_index 完全没有语义说明，在 schema 覆盖率为 50% 时描述未能完全弥补歧义。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具用途：按业务字段和记录索引解析单元格地址（col/row）及当前值；并通过与 find_cell 的对比（不依赖文本、走 VTable 内部映射）清晰区分了同类工具。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
给出了相对 find_cell 的使用理由和稳定性优势，暗示需要按字段+索引稳定定位时应使用本工具；但未明确说明何时应使用其他替代工具，也未解释 tab_id/table_index 的选择场景。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description consistently describes a read-only bind+return operation. It adds the behavioral trait that this call establishes a persistent binding reused by later VTable tools, which goes beyond the annotation and helps the agent understand stateful implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The purpose is front-loaded, and the binding consequence is stated immediately after, making it easy to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the binding behavior and the returned metadata. Since an output schema exists, the return format is handled there. It could mention prerequisites like requiring an active VTable, but that is implied by 'active page', so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (tab_id and table_index) already have detailed descriptions in the schema. The tool description only reinforces that table_index can be omitted, which duplicates schema information, so it adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'bind' and the resource 'VTable in the active page', and lists the exact metadata returned (rows/columns, header rows, frozen cells, canvas position/size, instance type). It also distinguishes itself from sibling VTable tools by positioning itself as the binding/overview tool, so an agent knows it is the entry point for VTable operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that subsequent VTable tools reuse this binding and that table_index can be omitted, giving a clear 'use this first' pattern. It doesn't explicitly mention alternatives or when not to use it, but the binding concept makes the intended sequence unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

DrissionPage-MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![DrissionPage-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/hooplus1ce/DrissionPage-MCP/badges/card.svg)](https://glama.ai/mcp/servers/hooplus1ce/DrissionPage-MCP)

Score Badge

Copy to your README.md:

[![DrissionPage-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/hooplus1ce/DrissionPage-MCP/badges/score.svg)](https://glama.ai/mcp/servers/hooplus1ce/DrissionPage-MCP)