qa-automation-mcp-plugin

by hooplus1ce

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes, especially the vtable_* family which is subdivided by action (get, scan, scroll, select, drag). A few pairs like vtable_analyze_headers and vtable_scan_columns overlap in analyzing headers, but descriptions clarify their different outputs. Overall, agents can tell tools apart with careful reading.
Naming Consistency4/5
Tools generally follow a verb_noun pattern in snake_case (e.g., click_interact, fill_input, capture_screenshot). The vtable_* prefix creates a consistent subsystem, though 'mimo_describe_image' breaks the pattern by leading with a noun and 'execute_and_record' uses a conjunction while 'execute_action_chain' uses a modifier. Still, the overall pattern is predictable.
Tool Count3/5
With 24 tools, this is on the heavy side, but the breadth reflects the complexity of QA automation including full VTable support. Each tool serves a distinct function, and the count is justified by the domain, though it demands careful selection.
Completeness4/5
The server covers the full recording lifecycle (start, execute, export), generic interaction (click, fill, chain, wait), page analysis, and a deep VTable toolkit. Minor gaps include no dedicated hover, keyboard shortcut, or element state assertion, but these are workarounds via execute_action_chain and wait_for_condition.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it initializes a new session, without clarifying side effects (e.g., whether it clears previous recordings), required prior state (e.g., a loaded page), or what happens on repeated calls. This minimal disclosure is insufficient for a tool that likely mutates state.
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 with no redundant words. It is front-loaded with the primary action. However, the conciseness comes at the cost of necessary detail, making it under-specified rather than efficiently packed.
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?
Despite having an output schema, the tool has 3 required parameters with no descriptions, no annotations, and no usage context. The description fails to explain how this tool fits into the broader recording workflow or what the parameters represent. This is a significant gap given the tool's complexity (multiple required params) and the many sibling tools.
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 0% description coverage, and the tool description does not mention any of the three parameters (flow_name, system_under_test, description). Since schema coverage is low, the description was expected to compensate by explaining parameter meanings or relationships, but it does not. This leaves the agent to infer semantics solely from parameter 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's function: initializing a new automated test case recording session. It uses a specific verb (initialize) and resource (recording session), which distinguishes it from sibling tools like export_session or execute_and_record.
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 prerequisites, sequencing relative to other recording tools, or scenarios where this tool is preferred. There is no exclusionary or contextual information.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions real-time recording and 'optimal high-resilience semantic positioning', but does not explain failure modes, waiting behavior, prerequisites, or side effects. The agent lacks critical information about what happens when elements are not found or how iframes are handled.
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, dense sentence that conveys the main purpose without fluff. It front-loads the core action and recording, but the multiple modifiers make it slightly verbose. Overall, it is efficient and logically structured.
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 tool's complexity (6 parameters, recording behavior, iframe support), the description is incomplete. It fails to provide context for parameter usage, prerequisites, or edge cases. The presence of an output schema reduces the need to explain return values, but the description still lacks crucial input semantics and behavioral 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?
Schema coverage is 0% with no parameter descriptions, and the description provides only indirect hints (e.g., 'input/click' maps to action, 'UI component adapter' hints at element_css). It does not clarify the meaning or usage of value, expected_result, iframe_selector, or description, leaving these parameters 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 tool executes UI actions (input/click) and records robust semantic positioning steps to the test case. This dual function distinguishes it from sibling tools like click_interact and fill_input, which only execute actions without recording.
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 scenarios requiring both execution and recording of steps, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. No direct mention of simpler tools for pure execution, leaving the agent to infer the intended 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?
No annotations are provided, so the description carries the full burden. It discloses that coordinates are precisely calculated via scenegraph and are directly usable with click_interact without offset, which is valuable behavioral context. However, it does not explicitly state that the tool is read-only or mention any potential performance costs, limitations, or side effects, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with the main purpose front-loaded and the key coordinate usage explained in a few sentences. The bold segments and 'recommended' tag add emphasis without unnecessary verbosity. It is not as tight as a two-sentence description, but each sentence contributes meaningful 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 covers the core behavior, outputs, and integration with click_interact, which is good for a scan tool with an output schema. However, it omits explanation of the input parameters and does not explicitly differentiate from similar sibling tools like vtable_analyze_headers. It is adequate but leaves gaps in parameter understanding and tool selection 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?
Schema description coverage is 0%, and the description does not explain the meaning or usage of max_col or iframe_selector. The agent must infer their purpose from parameter names and defaults, which is insufficient. The description entirely 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans all columns of a VTable (including multi-level headers) and returns specific outputs: column titles, body behavior classification, and header icon viewport coordinates. It uses a specific verb ('scan') and resource ('VTable columns'), and the mention of scenegraph-calculated coordinates strongly differentiates it from generic sibling tools, though it doesn't explicitly name an alternative.
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 the use case: '用于规划列头点击（排序/筛选/下拉图标）与列交互' (for planning column header clicks and column interactions). It also explains how to use the returned coordinates with click_interact, providing clear context on when to invoke this tool. It does not mention exclusions or alternatives, but the usage guidance is sufficiently clear.
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?
No annotations are provided, so the description carries the full burden. It mentions the primary action (ending the session) and outputs (JSON, Excel), but does not disclose whether the session is destroyed, if actions are reversible, permission requirements, or any side effects. This lack of behavioral detail is a notable gap for a tool that terminates an active state.
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, front-loaded sentence that immediately states the primary action and the key deliverables. Every word contributes to understanding the tool's purpose, with no redundant filler or repetition of schema 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?
The tool is simple with zero parameters and has an output schema, so the description need not detail return values. However, it does not mention that this is the final step in a recording workflow, nor does it warn about the potential destructiveness of ending the session. Given the available context, the description covers the essentials but lacks some operational context.
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 tool has zero parameters, so the schema carries no meaning to add. According to the rubric, a 0-parameter tool baselines at 4, and the description does not need to explain parameters. The description adds value by describing the output artifacts, but this is separate from parameter semantics.
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 ends the recording session and generates test assets in JSON and Excel formats. It uses specific verbs (end, package, generate) and identifies the resource (recording session, test assets), distinguishing it from sibling tools like start_recording or execute_and_record.
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 usage context is implied: it is the final step after recording to export results. However, there is no explicit guidance on when to use it over alternatives, no mention of prerequisites, and no exclusions. This aligns with an 'implied usage' level rather than clear guidelines.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does describe output content (text, attributes, HTML, interactive elements) and the 'detail' parameter's pruning behavior, but it does not explicitly mention side-effects (likely read-only) or the polling/waiting behavior implied by wait_ms and poll_interval_ms.
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 packs the tool's purpose, target, output details, and parameter options efficiently. There is no redundancy or wasted words, making it highly concise for the amount of information conveyed.
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 has four parameters, no annotations, and an output schema that is not visible in context. The description covers the core purpose and output format, but omits details about wait/poll timing, iframe selection specifics, and potential error conditions. This leaves some gaps for safe invocation, especially for a tool that interacts with dynamic UI after actions.
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?
With 0% schema description coverage, the description adds meaning for 'detail' (brief/full) and 'iframe_selector' via 'specified iframe', but does not explain wait_ms or poll_interval_ms. These parameters are somewhat self-explanatory from their names, but the description does not fully 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 function: probing visible dynamic layers (popups, message bubbles, dropdowns, date pickers, cascading layers) that appear after interaction, and returning internal text, attributes, HTML, and interactive elements. It uses a specific verb and resource, and the scope ('current page or specified iframe') distinguishes it from general page analysis tools like analyze_current_page.
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 usage after interaction with dynamic UI elements, and mentions the option to target a specific iframe. However, it does not explicitly state when not to use this tool or name alternative tools, though the specialization is clear enough from the 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?
With no annotations provided, the description carries the full burden. It discloses that the tool will force a browser connection, address an iframe, and overwrite window._vtable with the latest instance. However, it does not mention side effects, failure conditions, or the need for a loaded page, leaving some behavioral transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the main action and purpose. Every sentence adds information without redundancy, achieving high conciseness.
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 the tool's purpose and typical placement in the workflow, matching the existence of an output schema and a single optional parameter. It lacks explicit notes on requirements (e.g., page must be loaded) or when to re-run, but overall it is reasonably complete for a setup step.
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 no description for the single parameter, leaving 0% schema description coverage. The description mentions 'in the target iframe', which implicitly relates to iframe_selector, but it does not explain the parameter's role, format, or default behavior. Some compensation exists, but it is not comprehensive.
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 provides a specific action: force-connect to the browser, locate the target iframe, and refresh the latest vtable instance to window._vtable. It also distinguishes itself from sibling VTable operations by noting it is a prerequisite, making the tool's role in the workflow 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?
The description explicitly states the tool is typically a prerequisite for other VTable operations, giving clear guidance on when to use it. It does not mention alternatives or exclusions, but for a setup/reference operation, this is sufficient 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?
With no annotations, the description carries the full burden. It adds useful behavior details like recursion into nested iframes and generation of locators, but it does not explicitly state whether the operation is read-only or if any side effects occur. This leaves some ambiguity about the tool's safety profile.
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, focused sentence in Chinese that gets straight to the point. It conveys the main purpose, scope (recursive, iframes), and output (locators) without any wasted 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?
Despite having no parameters, the tool's complexity includes iframe recursion and locator generation. The description covers the core functionality and mentions iframe handling; the output schema presumably details the return structure. It is comprehensive enough for a 0-parameter tool.
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 tool has zero parameters, and the schema confirms this with 100% coverage. The description does not need to elaborate on parameter meanings, and the baseline of 4 is appropriate since there are no parameters to clarify.
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 'analyze' and the resource 'current Chrome page', and specifies that it recursively extracts visible interactive elements and generates locators. This distinguishes it from action-oriented siblings like click_interact and fill_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 the tool is used to gather locators for subsequent interactions, but it does not explicitly state when to use it versus alternatives or provide exclusions. Context suggests it should be used before clicking or filling, but that guidance is not spelled out.
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?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses crucial behaviors: empty value clears the field, type triggers keyboard events, fill uses native filling, clear_first defaults to clearing, press_enter can be enabled, and visualize has a three-state behavior. It also reveals the return structure (visual_effects + observation), giving a clear picture of what happens.
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 dense paragraph packed with information, with no filler or redundant words. It front-loads the purpose and then efficiently lists parameter behaviors. While concise, it could benefit from bullet points or separation for easier scanning, but every sentence earns its place.
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 11 parameters, no annotations, and an output schema, the description covers the core behaviors, input methods, return structure, and most parameters. It lacks explanation for 'description' and 'expected_result', and provides no error-handling or failure behavior, but for the typical use case it is fairly complete. The output schema handles return-value details.
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 0%, so the description must compensate, and it does for most parameters: by, selector, iframe_selector, value, input_method, clear_first, press_enter, detail, and visualize all receive explanations. However, 'description' and 'expected_result' parameters are not mentioned, leaving a small gap. It adds significant semantic value beyond the bare 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 '文本框输入工具' (text box input tool) and details the mechanism for targeting elements via by/selector, including iframe penetration. It distinguishes itself from siblings focused on clicks or table operations, though it doesn't explicitly name alternatives. The 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts by explaining input methods (type vs fill), clear_first behavior, and press_enter, but does not explicitly state when to choose this tool over siblings or when not to use it. It provides parameter-level guidance but lacks strategic usage direction. No alternatives are named.
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，描述承担全部责任。它披露了'无损'、'一次性'、'后台数据'、'无需操作 DOM'等关键行为特征，比简单说'获取记录'更具信息量。但未讨论错误处理或大规模数据时的限制，略显不足。
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，描述对用途和行为有一定覆盖，但未解释参数含义，也未说明与其他表格工具的限制边界。整体可用但有明显缺口。
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 描述覆盖率为 0%，描述中完全未提及 iframe_selector 参数，也未能补偿参数含义。尽管参数名和默认值提供了一些线索，但描述本身没有增加任何参数相关的语义。
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?
描述使用明确动词'读取'并指明资源为'表格中所有的完整后台行记录对象 (JSON)'，与 vtable_get_cell_text 等姊妹工具形成清晰区分。还提供了具体用途'整表断言和宏观数据检查'，信息充分。
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?
描述了适用场景'整表断言和宏观数据检查'，并说明'无需操作 DOM'，给出了行为边界。但未明确排除其他工具或提及替代方案，因此未达到满分。
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?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: it reads internal record collection length and is not affected by screen scroll truncation, which tells the agent this is a non-destructive, direct read. It also scopes to '纯数据' (pure data), clarifying it excludes headers/UI chrome. This goes beyond the simple function name, though it doesn't mention side effects or permissions (which are likely minimal for a getter).
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 front-loads the main purpose and then adds two key behavioral details ('directly reads internal record collection length', 'unaffected by scroll truncation') with no wasted words. It sets a good balance of brevity and substance.
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 getter tool with an output schema present, the description adequately covers the core function and the unique aspect of scroll-independent counting. The main gap is the unexplained `iframe_selector` parameter, which is optional and defaults to a reasonable selector, so it does not severely impair completeness. The presence of an output schema covers return-value expectations.
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 `iframe_selector` has zero schema description coverage (no description in the schema), and the tool description does not mention it at all. The parameter's purpose is left entirely to inference from its default value, which is insufficient compared to the baseline of 3 for covered schemas.
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: '读取当前 VTable 表格有多少行纯数据' (read how many rows of pure data the current VTable table has). It uses a specific verb ('读取') and resource ('当前 VTable 表格'), and the additional detail '不受屏幕滚动截断影响' distinguishes it from visible-row count methods, setting it apart from sibling vtable 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 clear context that it reads the internal record collection length and is unaffected by scroll truncation, implying it is the tool to use when a true data row count is needed regardless of scroll position. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight and does an excellent job. It discloses sequential execution, single observation at the end, stop_on_error default and behavior, fallback attempt ordering, automatic role/css/list-item variant appending, and that error messages include number of attempted locators. This is rich behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, with every sentence adding value. It is somewhat long but well-structured, proceeding from core function to failure handling to fallback advice. Slightly verbose but justified by the tool's complexity.
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 complex multi-action nature of the tool, minimal annotations, and non-descriptive schema, the description covers essential context: execution order, return value, error handling, and fallback behavior. It doesn't explain output schema details, but mentions observation return type, which is sufficient. Overall it's complete enough for an agent to decide and invoke correctly.
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 coverage is 0%, but description compensates by enumerating fields within each action (action, by, selector, iframe_selector, value, click_type, input_method, clear_first, press_enter, key, description) and explaining stop_on_error and fallbacks. It doesn't describe every parameter exhaustively, but provides enough meaning for an AI agent to construct valid calls.
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?
Description clearly states it's a batch action chain executing click/fill/select_option/press sequentially in one call, which distinguishes it from individual action tools like click_interact and fill_input. It doesn't explicitly name sibling alternatives but conveys the batch-execution purpose and return 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 states '用于减少 Agent 往返' (to reduce agent round-trips), which indicates when to use it instead of multiple individual calls. It also explains fallback usage for ambiguous actions, giving practical guidance for when to configure fallbacks, though it doesn't explicitly say when not 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully reveals that the tool delegates image understanding to an external model (MiMo-V2.5), which is a key behavioral trait beyond the name. It also mentions accepted input types (local paths, public URLs, pasted images) but omits potential caveats like privacy, failure modes, or latency. Still, the core delegation behavior is transparently disclosed.
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, front-loaded with the critical usage condition, and structured logically: first the fallback purpose, then the action, and finally the prohibition. Every sentence carries necessary information and there is no redundant wording or filler.
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?
Overall, the description is sufficient for tool selection: it clarifies the fallback scenario, the input sources, and the output type. However, it is less complete for invocation because several parameter semantics are missing and there is no guidance on how to configure 'thinking' or 'extract_pasted' for different use cases. The output schema exists, so return value details are not needed, but the input parameter ambiguity lowers the completeness.
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 does not explain most parameters. It indirectly describes the 'images' parameter by mentioning local paths, URLs, and pasted images, but 'question', 'thinking', and 'extract_pasted' are left completely unexplained. Since the description must compensate for the lack of schema docs but only partially does so, 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 identifies the tool as a fallback vision recognition tool that sends images to the MiMo-V2.5 model and returns textual descriptions. It specifies the resource (images) and the action (describe), and it is easily distinguishable from sibling tools, which focus on browsing, recording, or table manipulation.
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 the tool (only when the current main model is a pure-text model that cannot recognize images) and when it is absolutely forbidden (when the main model already has native multimodal capabilities). It also lists alternatives by naming the multimodal models that should be used instead, providing clear and complete usage 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?
With no annotations, the description carries the full transparency burden. It discloses chain-penetration via iframe_selector, coordinate_space semantics, detail output control, and the tri-state visualize. It also outlines return structure including visual_effects and observation components, though it omits side effects or error handling.
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 information-dense but well-organized with semicolons, covering many aspects without redundancy. It could be slightly easier to scan, but every sentence adds value.
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 complexity (13 params, no annotations), the description covers targeting modes, output details, and navigation comparison. The presence of an output schema reduces the need to document return values exhaustively, but error behavior and wait conditions are absent.
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 coverage is 0%, so the description must compensate. It explains most key parameters: by, selector, role, name, x/y (through coordinate), coordinate_space, click_type, detail, visualize, and iframe_selector. It does not mention description or expected_result, but those are self-evident metadata fields.
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 opens with '统一点击工具' (unified click tool), clearly stating its function. It enumerates three targeting modes (css/xpath selector, role+name, coordinate) and mentions the ability to click inside VTable, distinguishing it from siblings like fill_input or execute_action_chain.
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 usage context by suggesting by=role for Portal popups and by=coordinate for VTable internal clicks, which helps select the mode. However, it does not explicitly compare with sibling tools or state when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently explains the stateful nature: first call auto-locks a tab, subsequent operations stay fixed, and this tool changes that binding. It also mentions the return value (new target URL/title), but does not discuss error cases or potential side effects, hence a 4 rather than 5.
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 dense sentence but covers purpose, usage context, behavioral detail, and return value efficiently. It is not excessively long, but the information is packed together with semicolons, making it slightly harder to parse than if it were split into separate sentences.
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 stateful complexity, the description covers the essential aspects: what it does, when to use it, how it behaves, and what it returns. The presence of an output schema covers return format details. It lacks explicit mention of error handling if no tab matches, but overall it is complete enough for an agent to use correctly.
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 0% and there is one required parameter, url_pattern. The description adds the key semantic that this is a URL substring matcher, which is essential for understanding the parameter. However, it omits details like case sensitivity or whether the pattern must be a full URL, so slightly less than a 5.
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 ('显式切换/重绑' = explicitly switch/re-bind) and the resource ('MCP 操作目标标签页' = MCP operation target tab). It also specifies the matching method (by URL substring) and the locking behavior, making it distinct from sibling tools like analyze_current_page or export_session.
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: it explains the default automatic tab-locking behavior and specifies when to use this tool (when test page is accidentally closed or another system page needs to be operated). It does not explicitly name alternative tools, but no sibling tool serves this exact tab-rebinding purpose.
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?
With no annotations, the description carries the full burden. It explains that it is scene-graph driven, that header_icons include directly clickable top-level coordinates, that cell_icons are not in configs and only obtainable from the scene graph, and that capabilities summarizes interactive features. This adds meaningful behavioral detail beyond the tool name.
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 compact and front-loaded, using semicolons to efficiently list output fields and ending with a clear use-case clause. Every sentence adds value, with no redundant phrasing.
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 description fully covers the returned components (header_icons, cell_icons, capabilities) and their behavioral implications for clicking. Given the read-only nature and presence of an output schema, this is complete and actionable 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?
Schema description coverage is 0% since the description omits the sole parameter (iframe_selector). However, the parameter is optional, has a default value, and is self-explanatory from its name. The description's rich output semantics compensate somewhat, but it does not address the parameter at all, 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 it 'analyzes interactive icon components in vtable column headers and cells' (分析 vtable 列头与单元格内的交互图标组件), with a specific verb and resource. It distinguishes itself from sibling vtable tools by focusing on rendered icons with viewport coordinates and a capabilities summary.
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 and an intended use case ('用于规划列头点击与行内交互'), indicating when to use it. It does not explicitly name alternative tools or when not to use, but the context is unambiguous.
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?
With no annotations provided, the description carries the full burden and does well: it discloses the internal pipeline (instance refresh, checkbox column location, coordinate calculation combining iframe and canvas offsets, real mouse click), reports before/after changes, and lists automatic observations for popups and navigation changes. It does not mention potential wait times or error conditions, so it is not a perfect 5.
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, front-loaded paragraph that logically proceeds from purpose to mechanism to parameters to observations. Every sentence contributes necessary information, though it is fairly long and dense with technical detail, lacking the extreme brevity of a perfect example.
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 tool with significant complexity (canvas rendering, coordinate math, synthetic clicks), the description covers the mechanism, parameters, and return observations. The only notable omission is a fuller explanation of iframe_selector, but the default value and the offset explanation make it usable. Overall, the description is sufficiently complete for an agent.
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 0%, so the description compensates by explaining row_indexes as zero-based data row indices and action with default, options, and semantics (check/uncheck/toggle). However, iframe_selector is not explicitly described, although the mention of iframe offset calculations provides partial context. This is a minor gap for a defaulted parameter.
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 opens with '勾选/取消勾选 VTable 表格中的行' (check/uncheck rows in VTable), specifying the exact action and resource. This clearly distinguishes it from sibling vtable_get_* tools which read data or analyze headers, making the tool's purpose unmistakable.
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?
It explains that VTable is canvas-rendered with no DOM checkboxes, implying that this tool is the correct choice for selection tasks that generic click_interact cannot handle. It details the action semantics and idempotency, but does not explicitly name alternative tools or describe when not to use this tool, stopping short of a full 5.
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?
With no annotations, the description carries the full burden. It discloses the coordinate space (top-level viewport), the computation method (scene graph globalAABBBounds), and that iframe/container offsets are included. This is rich behavioral context beyond the schema. It doesn't explicitly state read-only, but '读取' (read) implies it, and the description adds valuable details about the calculation and use case.
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 concise sentences, front-loading the core outcome (viewport coordinates) and the intended use (click_interact). The second sentence efficiently clarifies parameter semantics. Every word earns its place, with 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 moderately complex (computes coordinates with iframe/container offsets) but the description covers the essential aspects: purpose, parameter semantics, coordinate space, and how to use the output. Since an output schema exists, return-value details aren't needed. It doesn't discuss edge cases or errors, but for a read-only getter with these annotations, it's adequately complete.
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 0%, so the description must compensate. It explains col_field (supports column index, field name, or column title) and row_index (pure data row number, 0-based). This adds meaning beyond the raw schema. However, the optional iframe_selector parameter is not mentioned, leaving a small gap in an otherwise well-documented set.
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: reading cell center top-level viewport coordinates. It uses a specific verb ('read') and resource ('cell center coordinates'), and differentiates from sibling tools like vtable_get_cell_text by explicitly focusing on coordinates for clicking. The direct reference to click_interact further clarifies its unique role.
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 the tool: when you need clickable coordinates for a cell, specifically as input to click_interact. It implicitly distinguishes from text/render-info getters, though it doesn't explicitly name alternatives or state when not to use. The instruction that coordinates can be directly used for click_interact is a strong usage guideline.
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?
No annotations are provided, so the description carries the full transparency burden. It discloses that this is a read operation ('读取'), that detail='full' includes all nodes, and clarifies row_index semantics. However, it does not explain the behavior of the iframe_selector parameter or any potential side effects, though for a getter this is acceptable.
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, front-loaded with the primary purpose and immediately followed by essential parameter usage. Every sentence adds value with no fluff or repetition.
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?
Overall, the description covers purpose, key parameters, and the intended assertion scenario. An output schema exists, so return-value details are not required. The only notable omission is the iframe_selector semantics, which is a minor gap given its default value.
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 0%, so the description must compensate. It explains col_field (column index or field name/title), row_index (0-based data row), and detail (full includes all nodes). The iframe_selector parameter is left unexplained, but the other critical parameters are well documented.
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 opens with '读取某个单元格的场景图渲染详情' (read the scene graph rendering details of a cell), which is a specific verb+resource. It enumerates the exact data returned (visual text, colors, border, font size, nodes), making it clear and distinguishable from siblings like vtable_get_cell_text or vtable_get_cell_center.
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 final clause '用于断言单元格的展示样式（标签色、高亮等）' explicitly states the intended use case: asserting display styles. It gives clear context for when to invoke this tool, though it does not explicitly name alternative tools or exclusions, which is a minor gap.
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?
No annotations are provided, so the description carries the full burden. It discloses a significant behavioral nuance: raw=false returns rendered visual text whereas raw=true returns raw field values, and it mentions the return includes missing columns. It does not state explicit side effects or prerequisites but implies a 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 two sentences, front-loaded with the main purpose, and packed with essential information without any fluff or repetition. It effectively explains the tool's function, parameters, and return behavior.
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 purpose, key parameters, and return summary, while the output schema provides formal return structure. It lacks explicit prerequisites or exclusions, but given the tool's relatively simple read nature, it is sufficiently complete.
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?
With 0% schema description coverage, the description compensates by explaining the key parameters: titles (array, with example) and raw (boolean, with behavioral difference). It omits iframe_selector, but that parameter has a default and is less user-facing.
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 all cell values in a column by Chinese title, using specific verbs and resource. This distinguishes it from sibling tools like vtable_get_cell_text (single cell) and vtable_get_all_records (all records).
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: to retrieve column values by title, with an explanation of the raw parameter's behavior. It does not explicitly name alternatives or exclusion cases, so it misses the top score but is still clear.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals important behaviors: it polls, returns the last status snapshot on timeout, and does not throw. It also defines condition semantics (element_hidden matches invisible or non-existent, text_present searches iframe or all frames). This goes beyond simple safety hints and adds meaningful 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 dense but well-structured: a purpose statement, a colon-separated list of conditions with parameter meanings, and a practical example. Every clause adds value, with no fluff. The front-loaded purpose and clear list make it highly scannable despite the length.
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 complexity (5 condition types, 7 parameters, no annotations, output schema exists), the description covers critical aspects: use case, condition semantics, timeout behavior, and return value. It does not explain edge cases like invalid conditions or the exact contents of the status snapshot, but the output schema likely handles return structure. Overall it is quite complete for a wait utility.
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 has no descriptions (0% coverage), but the description explains the meaning of most parameters. It details condition values and how they interact with selector, expected_text, exact, and timeout_ms. It also implies iframe_selector via 'target iframe' and uses example syntax. However, it omits poll_interval_ms and does not specify the structure of the returned status snapshot, so it is not fully complete.
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: 'wait for condition to be true (polling)'. It enumerates all supported condition types (element_visible, element_hidden, element_has_text, text_present, url_contains), making the scope explicit. The verb+resource is specific, and the list distinguishes it from sibling automation tools like click_interact or fill_input.
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 concrete typical use case: 'after submitting a form, wait_for_condition(condition='text_present', expected_text='新增成功', ...)' and explains that you should wait for the success message before assertion. It does not explicitly name alternatives or exclusions, but the example conveys clear context for when this tool is appropriate.
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?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the render-layer vs data-source distinction, the impact of sorting/filtering, and the viewport scrolling requirement — rich behavioral context beyond what schema could show.
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 somewhat long but every sentence adds value. It front-loads the core purpose, then parameter definitions, then the critical visual-mode caveat, and ends with the viewport constraint. Structure is logical and efficient.
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 read operation with no output schema and no annotations, it covers the key parameters, behavioral nuances, and a usage constraint. It could be more complete by describing the return type or potential errors, but these are minor omissions given the tool's simplicity.
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 has 0% description coverage, so the description compensates by explaining row_index, col_field, and visual in detail. The only parameter left unexplained is iframe_selector, which has a default but no narrative, so one gap remains.
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 opens with a specific verb and resource: '读取某个具体单元格的值' (read the value of a specific cell). It clearly distinguishes from sibling tools like vtable_get_all_records and vtable_get_column_values by focusing on a single cell.
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 clear guidance on when to use visual=True vs visual=False, explaining the sorting/filtering implications and the need to scroll to viewport rows. It does not explicitly mention alternatives among sibling tools but gives sufficient context for typical use cases.
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?
With no annotations, the description carries full behavioral burden. It discloses the CDP capture method (avoids font-loading hangs), file save location (evidence_assets/), return format (inline PNG + text summary), and full_page behavior. The description is transparent for a non-destructive tool, though it omits explicit notes on permissions or 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?
Single compact paragraph organized with semicolons, covering purpose, implementation, parameters, return value, and use cases without redundancy. Every clause provides actionable detail, making it appropriately sized.
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 two-parameter tool with no output schema or annotations, the description is fully self-contained: it describes what the tool does, how it works, parameter semantics, return payload (summary + image), and ideal use cases. No critical gaps remain.
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?
Schema descriptions are absent (0% coverage), so the description fully compensates by explaining both parameters: filename defaults to a timestamp and auto-appends .png, while full_page controls viewport vs. entire page capture. This adds significant meaning beyond the raw 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?
Description clearly states '截取当前页面截图' (capture current page screenshot) with specific CDP implementation, distinguishing it from sibling tools like analyze_current_page or start_recording. The tool's scope and return format (PNG) are explicit, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases with '用于视觉证据、页面状态留档、UI 断言前的实况确认' (used for visual evidence, page status archiving, and live confirmation before UI assertions). While it gives strong context, it does not explicitly exclude alternatives or name sibling tools for comparison.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details the exact interaction sequence (click header, stepwise drag, release), internal API usage for positioning and verification, and the return payload including column order and dragHeaderMode diagnostics. It also states error conditions clearly.
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 dense and every sentence adds value, but it is presented as a long unbroken paragraph with semicolons, making it harder to parse. It is front-loaded with the core purpose but could benefit from bullet points or clearer separation of behavioral steps.
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 tool's complexity (real mouse drag simulation) and the absence of annotations, the description covers prerequisites, execution method, verification details, return values, and error handling. The output schema exists, so return value details are not required in the description, but the description still provides sufficient context for safe usage.
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 0%, so the description must compensate. It explains source/target accept column index or field name/title, and describes the position parameter via 'before/after'. However, the iframe_selector parameter is not addressed, leaving a gap for that input.
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: dragging a vtable column (source) before/after another column (target) using real mouse drag. It explicitly differentiates from sibling tools by emphasizing that it does not use instance APIs to change column positions, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool by explaining it simulates real mouse drag rather than using APIs, and it outlines prerequisites (e.g., dragHeaderMode must be enabled) and error conditions. However, it does not explicitly name alternative tools or provide exclusionary guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden and does so admirably. It discloses internal API calls (scrollToCol/scrollToRow/scrollToCell/setScrollLeft/setScrollTop), the verify=True default with automatic visibility checks, return values (scrollLeft/scrollTop and cell visibility), and even recommends using vtable_get_cell_center after scrolling. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense yet well-structured with numbered usage modes and clear sentences. Every sentence contributes value, and the length is appropriate for the tool's complexity.
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 tool with 6 parameters and four usage modes, the description is exceptionally complete. It covers purpose, usage modes, parameter behavior, verification, return data, and follow-up actions. The only minor omission is iframe_selector, but it's not critical. With no annotations and no output schema details, this description goes above and beyond.
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 0%, so the description must compensate. It explains col_field types (int or string), the four usage modes clarifying parameter combinations, verify behavior, and scroll_left/scroll_top semantics. However, iframe_selector is not mentioned in the description, leaving a minor gap for this parameter.
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 'Scroll VTable to target position' and elaborates with four explicit usage modes, distinguishing it from sibling tools like vtable_get_cell_center and vtable_drag_column. The verb is specific, the resource is named, and the scope is well-defined.
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 provides an explicit priority list of usage modes based on parameter combinations, explains when to use each variant, compares to mouse dragging, and advises a follow-up step with vtable_get_cell_center for clicking. This gives clear when-to-use and includes alternatives.
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

Copy to your README.md:

[![qa-automation-plugin MCP server](https://glama.ai/mcp/servers/hooplus1ce/qa-automation-plugin/badges/card.svg)](https://glama.ai/mcp/servers/hooplus1ce/qa-automation-plugin)

Score Badge

Copy to your README.md:

[![qa-automation-plugin MCP server](https://glama.ai/mcp/servers/hooplus1ce/qa-automation-plugin/badges/score.svg)](https://glama.ai/mcp/servers/hooplus1ce/qa-automation-plugin)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hooplus1ce/qa-automation-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server