vtable-mcp

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.1.0
Disambiguation2/5
The set contains several near-duplicate actions: ui_click vs ui_interact, browser_open vs browser_start vs browser_connect, and ui_snapshot/ui_page_context/ui_analyze_scope/overlay_scan all probe overlapping page state. The detailed descriptions help only after an agent has already selected a tool; the boundaries are not immediately obvious.
Naming Consistency3/5
Useful prefixes like browser_, vtable_, ui_, and overlay_ exist, and names are consistently snake_case, but the style is mixed: browser_pages and vtable_meta are nouns, browser_open and vtable_read_cells are verbs, and case_execution_panel/mold_master_view are bare noun phrases. It is readable, but it does not follow a consistent verb_noun pattern.
Tool Count2/5
With 37 tools, this far exceeds the typical 3-15 tool range for one server. The surface bundles VTable automation, Playwright/CDP browser control, file management, Prefab UI generation, approval dialogs, and sample-data views, making it feel like several servers merged into one.
Completeness3/5
For VTable automation, the core read/click/analyze/navigate workflows are present, including browser session management and cell-level interaction. However, there is no direct cell-value editing or text-entry tool, and the many unrelated sample-UI tools obscure a clear end-to-end lifecycle, so some flows require workarounds.
Average 3.7/5 across 37 of 37 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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. It does disclose that a browser is opened, navigated, and reused, but it omits important behavior such as whether an existing session is replaced, what happens if the browser cannot open, or the effect of the default headless mode.
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 sentence with no filler words. It conveys the main action and the shared-session behavior efficiently, though it is terse enough to leave semantic gaps.
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?
For a browser-control tool with no annotations and minimal parameter coverage, the description is incomplete. It covers the overall purpose and the shared browser trait, but an agent would still lack guidance on headless behavior, session lifecycle, and how this operation relates to the browser_start/browser_connect siblings.
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 add meaning for either parameter. 'url' is only implied by 'navigate to target page', and 'headless' is not mentioned at all.
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 states a specific action ('open Playwright browser') and resource ('target page'), and adds the shared-browser behavior. It is clear, but it does not explicitly differentiate from sibling tools like browser_start or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the browser is reused by subsequent tools, but it gives no explicit guidance on when to choose this tool over alternatives such as browser_start or browser_connect. There are no exclusion conditions or when-not-to-use hints.
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?
无任何 annotations，描述承担全部行为披露责任，但仅说明了会话隔离和持久化能力，未披露各 action（list/create/select/save/close）的副作用——尤其 close 可能销毁会话、save 可能写盘、select 会切换当前活动上下文。这些行为在 schema 的 enum 中可见但无说明。
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?
单句中文描述，核心动词在前，能力细节随后，没有任何冗余词。长度与工具复杂度基本匹配，但考虑到 5 个 action 的多模式工具，信息密度仍有提升空间。
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?
这是一个包含 5 个 action、4 个参数、无 annotations 的会话生命周期管理工具，复杂度较高。描述未覆盖各 action 的具体行为、会话生命周期（select 切换后旧会话是否保留、close 是否销毁保存的状态）等关键决策信息。有输出 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%，描述必须补偿但只间接映射了 storage_state_path（通过"storage state 持久化"），对 name、session_id 的用途和 storage_state_path 是输入还是输出路径均未解释。action 枚举本身在 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?
描述使用了明确的动词"管理"和资源"隔离 BrowserContext 会话"，并补充了"账号 Cookie 环境切换"和"storage state 持久化"两个独特能力，能与 browser_start/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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
没有说明何时使用本工具而不是 browser_start、browser_connect、browser_close 等兄弟工具，也没有提及前置条件（如是否需要已启动的浏览器实例）或排除场景。使用场景只能从"会话管理"的语义中隐式推断。
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 carries the full burden of disclosing behavior. It only states that files are sent to the server, with no mention of side effects, authentication needs, file handling limits, overwrite behavior, or return values. "Manage files" is too vague to convey behavioral implications.
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 very short and front-loaded with the core purpose. Both sentences earn their place: one states the high-level function and the other clarifies the input mechanism. It could be tightened by replacing the vague "manage" with specific operations, but it is not bloated.
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?
The tool has no output schema and only an empty parameter schema, so the description must provide nearly all context. It does not explain how an agent should invoke the tool, what happens after upload, or what the response contains. This is insufficient for reliable tool selection and invocation.
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 zero parameters and 100% schema description coverage by default. The description adds a hint that the tool accepts files as a drop input, which is relevant context, though it does not define any programmatic parameter.
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 states a specific action, "Upload and manage files," and clarifies with "send them to the server." It identifies the resource as files, but "manage" is broad and does not fully differentiate from sibling tools like list_files and read_file.
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 use this tool versus alternatives such as list_files, read_file, or vtable_drop_files. The phrase "Drop files here" suggests a user-facing drag-and-drop context but does not help an agent decide when to select this tool.
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 behavioral disclosure burden. It adds useful context: addressing, scrolling, and centering are resolved internally via VTable APIs, and it uses Playwright trusted mouse input. It does not disclose verification/observation behavior, side effects, or failure characteristics, but the existing disclosure is substantive.
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 two sentences, front-loaded with the core purpose, and has no redundant wording. It could be slightly more structured with parameter hints, but it is appropriately concise for a tool whose behavior is partly encoded in its name.
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?
This is an 8-parameter tool with no annotations and no schema descriptions, yet the description only covers the two core inputs and a coordinate constraint. It does not explain the other six parameters, expected preconditions, or side effects; the output schema reduces the need to document returns, but the description is still far from complete for safe invocation.
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%, so the description must compensate for the eight parameters. It clarifies field and record_index as 'business field + record index', but says nothing about button, verify, settle_ms, max_results, double_click, or observe_after, leaving most parameters semantically opaque.
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 a specific action: 'click VTable cell by business field + record index', with a concrete verb and resource. The method distinction ('by_field') is present but it does not explicitly name or contrast with the sibling vtable_cell_click, so it stops short of a full 5.
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 the tool: when a cell is identified by business field and record index, and it explicitly tells the AI not to provide pixel coordinates. However, it gives no explicit guidance on when to prefer this tool over vtable_cell_click or other alternatives, nor does it state 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?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the token count is an estimate, but it does not state whether the call is read-only, what 'recent' means, or whether metrics are cumulative or scoped. This is minimal 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?
A single, front-loaded sentence states the returned quantities without filler. Every word contributes.
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 simple with one optional parameter and an output schema, so the description does not need to explain return shape. The only noticeable gaps are the undefined 'recent' window and unspoken limit semantics, which are minor for a low-complexity metrics 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 does not mention the limit parameter at all. The name and default imply it caps the number of returned metric records, but the tool description adds no meaning beyond the schema, so the agent must guess how limit affects the result.
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 names a concrete action and resource: it returns recent latency, response size, and token estimates for browser-side tools. This is enough to know what the tool does, but it does not explicitly differentiate it from sibling profiling/metrics tools such as ui_profile.
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?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no context such as checking performance before a task or after a browser action. The only hint is the tool's stated purpose, which leaves the selection condition to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does convey that the tool starts Chrome and automatically takes over via CDP, but it omits behavioral side effects such as occupying a port, launching a persistent process, or behavior when the port is already in 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?
A single, front-loaded sentence with no filler. It states the core action and mechanism immediately, and every word contributes meaning.
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 five parameters, no annotations, and non-trivial launch/takeover behavior, one sentence is insufficient. The description does not cover prerequisites, lifecycle expectations, or how this tool relates to the browser_* sibling tools, although the presence of an output schema partially accounts for return-value documentation.
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%, so the description needed to compensate, but it only indirectly references the port. The meanings and nuances of headless, timeout_ms, user_data_dir, and executable_path are left entirely to their names and default values in 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 identifies a specific verb ('start'), a resource ('managed Chrome'), and a mechanism ('CDP takeover') on a given port. This distinguishes it from sibling tools like browser_connect or browser_open, though it does not name alternatives explicitly.
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 intended use is implied: launch a managed Chrome instance before CDP-based interaction. However, there is no explicit guidance about when to use this tool versus browser_connect or browser_open, nor any exclusion criteria or prerequisite conditions.
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 must carry the full behavioral burden. It does not disclose whether the tool is read-only, whether it changes state, what data source it uses, or what invoking it returns. The word '模拟' hints at simulated content but does not clarify 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 a single compact sentence with no filler. It front-loads the resource and purpose and efficiently lists the two dashboard contents. Nothing extraneous appears.
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 zero-parameter tool, the core purpose is inferable, but the description lacks detail about what the invocation returns and whether it is purely observational. With no annotations and no output schema, the description only partially covers what an agent needs to know before calling.
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 an empty input schema, so there is no parameter meaning for the description to clarify. Under the zero-parameter baseline, the description does not need to compensate for parameter 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 identifies a specific resource ('VTable 引擎') and a clear function ('概览仪表盘' showing simulated table instance status and use case distribution). It does not explicitly differentiate from sibling dashboard/panel tools like case_execution_panel or vtable_meta, so it stops short of full clarity.
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?
There is no guidance on when to use this dashboard instead of related sibling tools, no conditions, and no exclusions. The agent must infer its usage from the name and content description 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the tool triggers backend execution and displays results, which is useful context. However, it does not mention side effects, required prior UI state, or how results are surfaced beyond a vague 'display' statement.
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 one-sentence flow diagram is compact, front-loaded with the tool name and purpose, and contains no filler. The arrow-based notation is efficient, though slightly telegraphic.
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 zero-parameter tool, the description is adequate but not fully complete. It conveys the core execution workflow and result display, but omits preconditions, expected UI context, and behavioral caveats. There is also no output schema to provide 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?
The tool has zero parameters and the input schema is an empty object with full coverage, so the baseline is 4. The description's references to selecting and submitting a case describe the intended workflow rather than parameters, and no parameter explanation is necessary.
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 identifies the resource (用例/test cases) and the execution operation, and it outlines the expected outcome (展示结果). The flow 'select case -> submit -> backend tool executes -> display result' makes the tool's role reasonably clear, though it does not explicitly distinguish itself from sibling tools like test_case_table.
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 a workflow but no decision guidance. It does not state when to use this tool versus alternatives, what preconditions exist (e.g., a case must already be selected), or when not to use it. Sibling tools suggest related functionality, but the description offers no comparison or selection criteria.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals only that the tool presents a dynamic form driven by built-in sample data, but does not state whether invoking it creates, updates, or writes data, whether it requires user interaction, or what side effects occur. Given the name suggests an entry/mutation operation, this is a meaningful transparency gap.
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 short sentence with the core purpose at the front and the dynamic-form detail immediately after. It does repeat the tool name's exact concepts, but the sample-data qualifier adds useful distinguishing information. It is concise and scannable.
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 zero-parameter, no-output-schema tool, the core invocation surface is covered: an agent knows it involves mold master data entry via a dynamic form. However, the description does not explain how this tool relates to siblings like mold_master_view, what happens after the form is used, or whether any follow-up action is expected. It is adequate but minimal for an agent deciding whether to call it.
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 zero parameters, and the description does not suggest any hidden inputs are needed. With schema description coverage at 100% and no parameters to document, there is little for the description to add. The no-parameter baseline of 4 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 identifies a specific action (录入, data entry) on a specific resource (模具主数据, mold master data), and adds the qualifier that it is a dynamic form driven by built-in sample data. This gives the agent a reasonable idea of what the tool does and distinguishes it from the sibling mold_master_view at a basic level. The description repeats the tool name's exact wording but is not purely a tautology.
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 use is implied by the word 录入 and the resource name, so an agent can infer it is for entering mold master data. However, the description does not explicitly explain when to use this tool instead of mold_master_view or the other form-related siblings, and it provides no exclusions or alternative routing. The guidance is present only by inference.
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 burden of behavioral disclosure. It clearly indicates a read-only operation ('Read') and what it operates on, but it does not mention edge cases, exact-name matching, side effects, or any limitations.
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 with no filler, starts with the core action, and immediately conveys the essential information. It is as concise as possible while still being meaningful.
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 tool with one required parameter and an output schema, the description is minimally sufficient but still lacks usage context and behavioral caveats. An agent can invoke it, but it would benefit from a note on sourcing the file name or on behavior when the file does not exist.
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%, so the description must compensate for the parameter. It only says 'by name,' which maps to the single 'name' parameter, but it does not clarify the expected format, whether the full filename is required, case sensitivity, or how the name relates to other tools like list_files.
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 uses a specific verb ('Read') and resource ('uploaded file's contents'), which makes the tool's purpose clear. It distinguishes from siblings like list_files and file_manager by focusing on reading contents rather than listing or manipulating files, though it does not explicitly name the alternatives.
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 for retrieving file contents by name, which is enough for a simple read operation. However, it provides no explicit when-to-use guidance, exclusions, or comparison against alternative file-related tools.
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 exist, so the description carries the full burden. It discloses the locator precedence, iframe priority, top-level coordinate semantics, and the exact result fields (base64, crop box, frame, locator source, hash). This is strong transparency, although it omits behavior around size limits or timeouts.
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?
Four compact sentences, each carrying useful information; the main purpose is front-loaded and technical details follow in a logical order. No 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?
For an 18-parameter tool with no annotations, the description covers the central selection logic and result shape, but it under-documents several input parameters and the interaction with siblings. The output schema presumably covers return values, so some completeness is recovered.
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 has 0% description coverage, so the description must compensate. It explains the core locator parameters (css, role, name, description, xpath, text, placeholder) and the x/y/width/height rectangle fallback, but it leaves many parameters (image_format, quality, max_bytes, padding, timeout_ms, in_iframe) undescribed.
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 opens with a clear verb and scope: capturing a DOM element or top-level viewport region and returning a resized image. It also outlines the locator fallback order, but it does not explicitly differentiate from sibling tools like ui_snapshot, so 4.
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 explains how element locators work and when to fall back to x/y/width/height, but it never states when to choose this tool over related siblings (e.g., ui_snapshot, overlay_scan). No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It accurately conveys a non-mutating read and adds the row-major traversal behavior, but it does not disclose coordinate conventions, endpoint inclusivity, reversed range handling, or error behavior on out-of-bounds coordinates.
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?
A single well-structured sentence that front-loads the action and resource, then adds the relevant row-major detail. There is no filler or repetition.
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 four-parameter read tool with an output schema, the description is nearly adequate, but it omits coordinate conventions and boundary-condition handling that an agent would need to call it correctly on unusual inputs. It also provides no guidance for choosing among the vtable siblings.
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%, so the description must compensate. It maps the four parameters to the two corners of a rectangle, which is meaningful, but it does not define bounds, inclusivity, or coordinate origin; the parameter names already suggest their column/row roles.
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 (batch read) and the resource (rectangular region of cells), and it adds the row-major ordering detail. It does not explicitly contrast with sibling tools like vtable_cell_info or vtable_cell_resolve, so it stops short of full sibling differentiation.
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?
There is no guidance about when to use this tool instead of vtable_cell_info, vtable_cell_resolve, or other vtable siblings, and no exclusions or prerequisites. The intended selection context must be inferred entirely from the name and the sibling 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?
With no annotations, the description carries the behavioral disclosure burden. It discloses built-in sample data and support for search/sort/pagination, which are useful. However, it does not explicitly state read-only behavior or side effects, so transparency is incomplete.
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 compact sentence that front-loads the resource name then lists capabilities. It contains no filler, repetition, or unnecessary detail.
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 zero-parameter tool, the description covers what the table contains and what interactions are supported. But since there is no output schema and no usage context, an agent is left uncertain about the exact return format and when to select this tool over sibling tools.
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 schema has zero parameters, so parameter semantics are not a real burden. The description's mention of built-in data and table capabilities is sufficient at the zero-parameter baseline.
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 identifies a specific resource (transfer-order test case summary table) and states it contains built-in sample data with search/sort/pagination. It is clear what the tool offers, though it lacks an explicit operation verb and does not differentiate from sibling table-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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement about when to use this tool or when to prefer a sibling like vtable_meta, vtable_read_cells, or case_execution_panel. The mention of built-in sample data weakly implies a demo/read-only context, but no explicit selection guidance is given.
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 disclosure burden. It adds one meaningful behavioral qualifier ('with metadata'), implying the tool returns file listing information rather than file contents. It does not disclose limits, ordering, filtering, or what 'uploaded' encompasses, though the existing output schema covers the return structure.
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?
A single six-word sentence that front-loads the verb and resource with zero filler. Every word earns its place, and the length is appropriate for a parameterless listing tool.
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 zero-parameter tool with an output schema, the description is nearly complete: the agent knows what action to take and what kind of result to expect. The only gaps are sibling differentiation (file_manager ambiguity) and clarification of the term 'uploaded', both minor 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?
The tool has zero parameters, so there is nothing for the description to explain beyond what the empty schema already conveys. Per the baseline for parameterless tools, this is appropriately handled.
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 uses a specific verb ('List'), a clear resource ('uploaded files'), and a scope qualifier ('all'), making the core action unambiguous. The 'with metadata' qualifier usefully signals that file contents are not returned, distinguishing it from read_file. However, it does not explicitly differentiate from sibling file_manager, which may also handle file operations.
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 file_manager or read_file, and states no exclusions or prerequisites. The intended use case (enumerate available files) is only weakly implied by the verb and resource; with 38 siblings, routing guidance would materially help an agent.
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 transparency burden; it does state that the tool is read-only and uses a built-in sample, which signals no mutation and fixed sample data. However, it does not describe return format, error behavior, or what 'rendering' produces.
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?
One short sentence, front-loaded with the tool's nature ('read-only view') and then a concise statement of content ('renders all fields, built-in sample'). No 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?
For a parameterless read-only view, the description captures the essential facts: read-only, all fields rendered, and sample data embedded. It lacks explicit context about why the sample exists or how the result is used, but nothing critical is missing for invoking the 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 empty schema already covers 100% of the interface, so the description needs to add no parameter information. Per the calibration baseline for 0-param tools, this is sufficient.
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 names the resource (模具主数据/mold master data) and the action (renders all fields in a read-only view). It is clear, though it does not explicitly distinguish itself from the sibling mold_master_entry or other view-like tools.
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 call this tool versus alternatives such as mold_master_entry, no exclusions, and no context about expected use case. The agent is left to infer the intended scenario.
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 must disclose behavior itself. It states the operation is an automated browser drag-drop via Playwright and explains the coordinate mapping, which is meaningful. It does not mention side effects such as file upload/change events, prerequisites like an active browser page, or reversibility, leaving some behavioral opacity.
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?
Three short sentences deliver purpose, mechanism, and parameter meaning with no filler. The key action is front-loaded, and each 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 definition covers the core invocation facts: what is dropped, where, and how coordinates are resolved, and an output schema exists for return details. It omits preconditions such as an active connected browser and a rendered .vtable container, and it says nothing about failure modes. For a browser automation mutation, this is a modest gap.
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 parameter descriptions, but the description defines files as server-side file paths and data as optional clipboard-style key-values. It only indirectly covers col and row as 'specified cell' coordinates and does not state zero-based indexing or coordinate conventions. This partial compensation earns a middle score.
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 names a concrete action (dragging server-side files) and a precise target (a VTable cell), backed by an exact API (Playwright Locator.drop). This clearly distinguishes it from sibling tools that click, read, or resolve VTable cells, even though no sibling is named explicitly.
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 its use case: simulating a drag-and-drop of local server files onto a VTable cell. It does not explicitly state when to prefer it over alternatives such as vtable_cell_click or vtable_cell_info, nor does it state when not to use it. Usage is inferred rather than explicitly routed.
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 disclosure burden — and it delivers substantially. It reveals the synthetic-but-trusted input pipeline (isTrusted=true), the scroll-to-viewport and deterministic-center-point mechanism, read-back verification of selection/editor state, automatic retry on miss, and the observe_after overlay-listening behavior across the main page and all iframes. Gaps are minor: it does not state side effects when a trusted click navigates or opens an editor, but the verification step partially covers this.
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 compact and front-loaded with the core action before the procedural detail. The flow is encoded as a dense parenthetical chain (绑定实例 → 滚动 → 取中心点 → 点击 → 验证 → 重试) that earns each element, and the observe_after behavior gets its own sentence. It is information-dense rather than bloated, though the long chain requires careful parsing.
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 complex 8-parameter tool with zero annotations and 0% schema coverage, the description covers the core workflow remarkably well and the output schema covers return values. However, half the parameters (button, settle_ms, max_results, double_click) lack any guidance, prerequisites beyond '绑定实例' are not elaborated, and failure retry behavior is only mentioned in passing. The tool is usable but an agent would still guess on several inputs.
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%, so the description must compensate. It does add real meaning: the (col/row,0起) coordinate system, the verify behavior via '回读选中区间/编辑器状态验证', and a thorough explanation of observe_after. However, button, settle_ms, max_results, and double_click remain completely unexplained — settle_ms and max_results in particular are opaque without context. Compensation is partial, roughly half the parameters.
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 opens with a specific verb+resource: '点击 VTable 指定单元格(col/row,0 起)' — clicking a designated VTable cell by 0-based col/row coordinates. This clearly distinguishes it from sibling vtable_cell_click_by_field (field-based) and generic ui_click, though it never explicitly names those alternatives. The core purpose is unambiguous and immediately actionable.
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?
Usage context is only implied through the detailed pipeline (bound instance → scroll to viewport → deterministic center point → trusted click → verify → retry) and the observe_after conditional. It signals this tool is for reliable, verified VTable interactions, but never states when to prefer it over vtable_cell_click_by_field, vtable_cell_resolve, or ui_click, and gives no exclusions. The conditional 'observe_after=True 时' is the only explicit selection guidance and concerns a mode, not tool choice.
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 of behavioral disclosure. It usefully reveals that the tool observes events across all iframes, operates within a limited window, and by default stops listening after sampling. This is meaningful non-obvious behavior, though it does not explicitly state whether the tool is read-only or describe 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?
Two focused sentences with no filler: the first states the scope and action, the second provides usage context and a key default behavior. Information is front-loaded and each 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 adequately covers what the tool does, when it is appropriate, and a key behavioral default, and there is an output schema to describe return values. However, the complete absence of parameter semantics and explicit sibling differentiation leaves noticeable gaps for an agent trying to invoke it correctly.
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 stop, settle_ms, or max_results. The phrase about stopping after sampling hints at the stop default, but it does not actually define the parameters or their relationships. At 0% coverage, the description needed to compensate and did not.
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 states a specific action and resource: collecting Ant Design Portal/ARIA overlay events within a limited window and covering all iframes. This clearly distinguishes the tool's core function from general UI tools, though it does not explicitly contrast with the sibling overlay_scan.
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 says this is suitable for diagnosis after page interactions have been triggered by other tools or manual actions, and notes that it stops listening after sampling by default. This gives clear context for when to use it, but it does not mention alternatives or state 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, the description carries the behavioral disclosure burden. It goes beyond a simple 'click' by revealing the return payload (Portal, hints, focused overlay), locator priority order, coordinate fallback behavior, and the rejection of stale VTable coordinates when `analysis_id` is provided. This is strong, though it does not cover all side effects or preconditions.
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 but information-dense. The first sentence gives the purpose and immediate result; the second lays out the locator order and fallback rule. Every sentence contributes, and the most important information is front-loaded.
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 16-parameter tool with no annotations and 0% schema coverage, the description covers the central behavior well but leaves several operational parameters undocumented. The presence of an output schema lowers the need to describe return values, yet the gaps around `frame`, `observe_after`, and `expect_input` mean the definition is not fully 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 0%, so the description must compensate. It does add real semantic value by explaining how CSS, role/name, XPath, text/placeholder, and x/y relate to each other, and by qualifying `analysis_id` behavior. But several parameters remain unexplained: `frame`, `settle_ms`, `timeout_ms`, `max_results`, `expect_input`, and `observe_after`, so compensation is only partial.
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 opens with a specific verb and resource: 'unified click page controls' and states what it returns (Portal, hints, focused overlay). It is clear about the core operation, but it does not explicitly differentiate this tool from the sibling `ui_interact`, so it falls short of a 5.
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 meaningful usage context: it says multiple candidate locators can be passed from analysis results, defines a fixed execution order, and marks coordinates as a fallback. However, it never says when to prefer `ui_click` over alternatives like `ui_interact` or `vtable_cell_click`, leaving the when-to-use guidance mostly implied.
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 burden of behavioral disclosure. The verb '返回' suggests a read-only retrieval, which is helpful, but the description does not disclose prerequisites such as an open page, whether the tool performs any actual clicking as part of verification, or any 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 sentence with no filler. It front-loads the verb and immediately lists the concrete outputs, making it easy to scan and understand.
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 no-parameter tool with an output schema, the description is mostly complete: it tells the agent what kind of data to expect. It could be stronger by defining what 'Profile' and '定位顺序' mean or clarifying that no clicks are actually performed, but the output schema likely covers return structure.
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 there is nothing to document beyond the schema. The description adds no parameter details, but none are needed; the baseline of 4 for a 0-parameter tool applies.
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 states a clear verb, '返回' (returns), and specifies three concrete outputs: current page Profile, positioning order, and VTable click verification order. It is specific enough to identify the tool's purpose, though it does not explicitly distinguish itself from sibling tools like ui_page_context, vtable_meta, or ui_analyze_scope, and some terms are domain jargon.
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 this tool is used when the agent needs the current page's Profile, positioning order, or VTable click verification order. However, it provides no explicit when-to-use or when-not-to-use guidance, and no alternatives are named, leaving the agent to infer the right context among many similar UI/VTable sibling tools.
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 of behavioral disclosure. It clearly reveals that this tool has a persistent side effect: later page, iframe, overlay, and VTable operations will be bound to the selected page. It does not mention failure behavior or reset semantics, but the key state-changing 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 a single well-structured sentence that front-loads the core action and then states the consequence. Every clause earns its place, with no filler or redundant restatement.
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 one-parameter tool, the description covers the main purpose and side effect, and an output schema exists so return-value details are not required. However, it leaves a notable gap: the agent is not told how to obtain a valid page_id (for example, via browser_pages), nor what happens if the page is invalid or not yet open. Overall it is workable but not fully self-sufficient.
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 input schema provides a single required page_id string, but schema description coverage is 0%. The description merely repeats 'page_id' without adding meaning: it does not explain where the id comes from, what format it expects, whether it must come from a prior browser_pages call, or how invalid ids are handled. Since the schema is minimal, the description needed to compensate and did not.
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 action ('显式选中' — explicitly select) and the target resource (a page_id), and explains the consequence that subsequent page, iframe, overlay, and VTable tools will use that page. This also distinguishes it from sibling tools like browser_open and browser_pages by making the context-selection role explicit.
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 conveys when to use the tool: when a specific page should become the fixed target for later tool calls. It does not explicitly name alternatives or exclusions, but the behavioral consequence ('后续...固定使用该页') provides clear usage context for an agent deciding whether to select a page before invoking other tools.
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 for behavioral disclosure. It usefully reveals that it uses VTable internal APIs, prefers getCellAddrByFieldRecord, falls back for old-version instances, and does not scan the DOM or guess coordinates. It does not explicitly state whether the operation is read-only or what errors may occur, but the disclosed constraints are meaningful.
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 three short sentences with no filler. The core purpose is front-loaded, implementation details follow, and the final sentence clarifies a key limitation. 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 the tool has an output schema, the description does not need to detail return values. It covers purpose, implementation strategy, version fallback, and the no-DOM-scan constraint. It could improve by naming when to choose this over sibling tools like vtable_cell_info or vtable_read_cells, but it is otherwise sufficiently complete for a moderately complex 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%, so the description must compensate. It identifies field as a 'business field' and record_index as a 'record index', but it does not explain when record_index is an integer versus an array, what field format is expected, or how multiple indices are handled. This is minimal semantic value beyond the 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 begins with a specific verb and resource: '将业务字段和记录索引解析为单元格地址' (resolve business field and record index into cell address). It also distinguishes itself from DOM-scanning UI tools by stating '不会扫描 DOM 或猜测坐标', making its role clear relative to 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 implies usage context—when you need an exact cell address from a field and record index—but it never explicitly names sibling alternatives or states when NOT to use this tool. The internal API preference and fallback logic describe implementation behavior, not user-facing selection criteria.
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 behavioral burden, and it mostly delivers. It discloses that the tool connects via CDP on port 9222, reuses pages and in-page instances, and that closing only disconnects without closing the external browser process. It does not cover connection failures or authentication, but the essential lifecycle behavior is 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 compact and front-loaded: the core action is in the first sentence, usage context in the second, and close behavior in the third. Every sentence adds distinct value, and there is no redundant restating of the tool name or schema.
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 tool's purpose, usage context, and non-destructive close behavior, and an output schema exists, so return-value documentation is not required. However, it omits the semantics of the cdp_url parameter and does not explicitly state when not to use this tool versus browser_start or browser_open. These are notable gaps for a connection tool with zero parameter-level schema descriptions.
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%, so the description must compensate for both parameters. It mentions the default port 9222, which helps with the 'port' parameter, but it never explains the 'cdp_url' parameter, its format, or how it interacts with 'port'. This leaves a meaningful gap for an agent deciding what to pass.
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: connect via CDP to an already-running browser. It clearly distinguishes itself from siblings by noting it reuses an external browser and its open VTable pages without navigation, and that closing only disconnects rather than killing the process. This makes the tool's role unmistakable relative to browser_open, browser_start, and browser_close.
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 gives clear context for when to use the tool: when you want to reuse an external browser with already-open VTable pages and drive them directly, avoiding re-navigation. It does not explicitly name alternatives like browser_start or browser_open as the contrast, but the 'reuse external browser' and 'no re-navigation' phrasing implies the alternative scenario well enough.
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 discloses that the tool lists all tabs across all BrowserContexts, provides stable page IDs, and marks the current selected page. However, it does not explicitly state that the operation is non-destructive or whether it changes the current selection.
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 front-loads the verb and scope, includes the key detail of stable page_id, and mentions the selected-page marker. Every word contributes; there is no 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?
For a parameterless listing tool with an output schema, the description is fairly complete: it specifies the scope (all BrowserContexts), the stable identifier, and the selected-page flag. The only missing piece is an explicit statement about read-only behavior, but the operation's nature and the output schema mitigate that.
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 fully documents that nothing is needed. The description correctly says nothing about parameters. Baseline 4 for zero-param tools 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 uses the specific verb '列出' (list) and clearly identifies the resource: all tabs across all BrowserContexts with stable page_id, and marks the currently selected page. This differentiates it from sibling tools like browser_select_page or browser_open by focusing on read-only listing rather than selection or creation.
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 for obtaining an overview of open pages, but it does not explicitly state when to use it versus alternatives such as browser_session or browser_select_page. No when-not scenarios or alternative tool names are mentioned.
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 the full burden, and it delivers: it states it reads only VTable API/scenegraph, never clicks or expands canvas DOM, returns absolute viewport coordinates, explains click_opens_dom_input, and documents multi-table catalog behavior and token-control modes. No contradiction with annotations exists.
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 purpose is front-loaded and nearly every clause adds behavioral or workflow value. The single dense paragraph is information-rich but would benefit from clearer separation of modes, catalog selection, and diagnostic toggles.
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 7-parameter tool with no annotations and an output schema, the description is almost complete: workflow, coordinate handoff, defaults, and diagnostic overrides are all covered. The missing semantics for max_columns/sample_rows and the lack of explicit sibling-tool exclusions keep it from a 5.
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 mode, fields, include_values, visible_only, and table_index. It leaves max_columns and sample_rows undocumented, so parameter coverage is strong but not complete.
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 opens with a specific verb and resource: scanning current VTable headers, interaction icons, and limited-value cells for interaction evidence. It clearly distinguishes the tool's scope, though it does not explicitly name sibling tools to contrast against.
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 provides operational instructions: first call returns a catalog when multiple VTables exist, table_index disambiguates, and interactive vs full modes are explained. However, it never states when to prefer vtable_analysis over alternatives like vtable_cell_info or vtable_read_cells, so usage boundaries remain implicit.
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?
While no annotations are provided, the description directly signals a read-only behavior through '读取' and enumerates exactly what information will be collected, including value, behavior classification, editability, center point, and viewport status. It also frames the tool as a verification mechanism, implying no state mutation. It could go further by mentioning error edge cases or whether the read has any layout/scroll side effects, but for this simple read tool the behavioral disclosure 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 compact: one sentence states the tool's function and output scope, and a second sentence gives the practical verification-loop usage pattern. There is no filler, and the most important information is front-loaded.
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 output schema covers return-value details, and the description explains what the tool reads and how to use it in before/after interaction verification. It is largely complete for a simple single-cell lookup, though it could be more complete by noting when to prefer sibling tools such as vtable_read_cells for bulk reads or vtable_meta for table-level metadata.
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 has 0% description coverage, and the description does not explicitly explain 'col' or 'row'. However, the parameter names are inherently clear as grid coordinates, and the surrounding '单元格' (cell) context makes their role obvious. The description adds no coordinate-system details or constraints, leaving only a minor gap.
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 opens with a specific action and resource: '读取 VTable 单元格信息' (read VTable cell information), and lists concrete aspects it returns: value, behavior classification, editability, center point, and viewport visibility. This clearly separates it from click/drop/analysis tools, though it does not explicitly distinguish it from similarly named siblings like vtable_cell_resolve or vtable_read_cells.
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 gives explicit usage guidance: call once before and once after an interaction so the AI can confirm the target and the result, referencing the Playwright MCP verification-loop idea. This is strong contextual guidance, but it does not name alternatives or state when not to use the tool.
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 some burden. It discloses that scanning is a static snapshot, mentions the risk of transient overlays disappearing, and describes returned fields. However, it does not mention side effects (though it's presumably read-only) or exact visibility/box semantics; still, it adds useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, then scope semantics, then return summary, then routing guidance. Each sentence adds value; the final sentence is a helpful warning. Slightly longer than necessary but 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 complexity of overlay scanning across iframes, the description covers the core selection logic, return summary, and the transient-overlay caveat. It lacks explicit mention of max_results bounding and exact 'active iframe' definition, but the output schema and defaults help. Overall sufficient for an agent to decide and invoke.
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%, and the schema only lists scope and max_results with defaults. The description explains scope values ('active' vs 'all') and max_results is not mentioned by name but is implied by '每个浮层' and '最多'? Actually max_results is not described; the description partially compensates for scope but not max_results. No parameter descriptions in schema, so baseline is low, but the description covers scope meaning partially.
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 ('Ant Design Portal / ARIA 浮层') within the current visible page, and clearly distinguishes the scopes. It also separates this tool from sibling overlay_observe and ui_analyze_scope by specifying it targets portals/ARIA overlays.
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 explains when to use scope=active vs scope=all, and provides a concrete 'when not to use' for transient message/toast by directing to ui_click or vtable_cell_click(observe_after=True). This is strong 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?
No annotations are provided, so the description carries the full burden. It openly discloses cropping behavior, iframe handling, and the fact that it does not expand the entire DOM. It does not explicitly state read-only/side-effect status or failure behavior, but the scoping caveats provide solid 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?
Three short sentences front-load the core purpose, then add conditional behavior and output format with no fluff. The structure is easy for an agent to parse and 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?
With an output schema present, the description does not need to detail return fields. The main gaps are undocumented parameters and no explicit alternative routing, but the scope, cropping, and iframe behavior are well covered, making it near-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?
Schema description coverage is 0%, and the description never mentions max_controls or max_overlays or how they affect the scan or result size. The compact-list promise only indirectly relates to max_controls, so the description does not compensate for the schema's lack of parameter 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 states a specific action ('analyze') and a bounded resource: operable controls within the current active page or focused overlay. It also distinguishes itself from full-page DOM inspection by promising a compact role/name/CSS locator list, which clearly separates it from siblings like ui_snapshot or ui_page_context.
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 concrete conditions: when Modal/Drawer/Dropdown/Popover is present it crops the underlying page, otherwise it scans the top-level document and active AntD Tab iframe. This gives clear context for when the tool applies, but it does not explicitly name alternatives or state 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.
Behavior5/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 locator resolution priority, x/y fallback behavior, validation behavior with analysis_id, iframe context selection, expect_input verification, and default post-click observation of portals/messages/dropdowns/notifications. This is unusually transparent.
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 but every sentence contributes: purpose is front-loaded, then resolution order, fallback semantics, validation, frame logic, and observation behavior. A bulleted or grouped structure would improve scannability, but the length is justified for a 20-parameter tool with no schema descriptions.
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?
Given the high complexity (20 params, no annotations, 0% schema coverage), the description covers behavior and many parameters well. However, it leaves critical gaps around valid action values and the meaning of value/key/in_iframe/settle_ms/timeout_ms. The output schema reduces the need to describe return values, but the missing action semantics prevents full self-sufficiency.
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 substantially by explaining css, role, name, description, xpath, text, placeholder, x/y, analysis_id, frame, expect_input, and max_results. However, the required action parameter's accepted values are not described, and value/key/in_iframe/settle_ms/timeout_ms are only implied or omitted.
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?
States a specific action ('executes unified DOM interactions') and target ('current page/active iframe'), and describes the returned focused overlay result. However, it does not explicitly contrast itself with siblings like ui_click or vtable_cell_click, so sibling differentiation is left implicit.
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 operational conditions: CSS is preferred when the analyzer returns it, x/y are only fallbacks, analysis_id triggers pre-execution validation, frame defaults to the active AntD tab iframe, and expect_input verifies focus. It lacks explicit 'when not to use this tool' or named sibling alternatives, but the within-tool usage context is strong.
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 the result is compact and low-token and lists the scoped context categories, which is useful. However, it does not explicitly state whether the operation is read-only, whether the context may be stale, or whether any side effects occur. For a context-reading tool this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core function and output scope; the second gives usage guidance and the relationship to ui_snapshot. Everything included 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?
The tool is simple, has an output schema, and one optional parameter. The description supplies the key routing decision against ui_snapshot and explains the compact nature of the result. The only real gap is the uninterpreted max_results parameter, which is minor but prevents a perfect score.
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 only parameter, max_results, has 0% schema description coverage and is not mentioned in the description. The name hints at a result cap, but the description adds no meaning beyond the raw parameter name and default value, so it fails to compensate for the low 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 opens with a specific verb, '返回' (return), and precisely enumerates the resource scope: current page, active iframe, and focused overlay. It also distinguishes itself from ui_snapshot by calling this a compact/low-token context, so an agent can tell them apart without opening schemas.
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 explicitly states when to use this tool: every time the AI prepares its next interaction, as a low-token entry point. It also says to continue to ui_snapshot only when a detailed control tree is needed, providing clear when-to-use and when-not-to-use guidance with a named alternative.
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 behavioral disclosure burden. It meaningfully explains the side effects: releasing resources, disconnecting external CDP browsers, and actually closing managed Chrome/Playwright browsers. This is strong behavioral transparency, though it could additionally mention idempotence or error 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 two short sentences with no filler. The primary action is front-loaded, and the important behavioral nuance about CDP versus managed browsers is delivered efficiently.
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 parameterless close-operation tool with an output schema present, the description is complete: it states the core action, the resource affected, and the key behavioral difference between connection types. Nothing essential for the agent to call the tool correctly is missing.
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 schema coverage is 100%, so there is no parameter burden on the description. The baseline of 4 applies because the description accurately reflects a parameterless operation without needing to add parameter-level detail.
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 uses a specific verb ('关闭' / close) and a clear resource ('Playwright 浏览器'), and further distinguishes behaviors for CDP-connected external browsers versus managed browsers. This clearly separates the tool from siblings like browser_open, browser_start, and 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 clearly implies when to use the tool (when a browser or CDP connection should be closed) and provides context about how different connection types are handled. However, it does not explicitly state alternatives, exclusions, or when not to use this tool, leaving the usage guidance mostly inferred.
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 behavioral burden and does substantial work: it explains that output includes refs and box coordinates, that selector scopes to a subtree, how frame routing works, and that VTable canvas cells are excluded. The only notable omission is the behavior/effect of the depth parameter.
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 front-loaded with the core purpose and then uses compact, well-separated paragraphs for VTable caveat, selector behavior, and frame modes. Every sentence adds useful information with no filler or restatement of the schema.
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 it equips an agent to call the tool correctly in most cases: purpose, output nature, frame semantics, selector scoping, and the canvas limitation are all covered, and an output schema exists. It falls short only on depth and lacks an explicit pointer to sibling vtable tools for canvas-cell access.
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 adds real semantics for boxes and ai_mode (mode='ai' + boxes), selector (subtree scoping), and frame (None/active/vtable/name-or-URL rules). However, depth receives no explanation, leaving one of five parameters under-specified.
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 '抓取页面 aria 快照(mode='ai' + boxes)' — a specific verb, resource, and mode — and frames the output as a '语义之眼' accessibility tree containing refs and viewport boxes. This clearly distinguishes ui_snapshot from screenshot/overlay siblings by presenting it as an a11y-tree reader.
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 gives an explicit when-to-use cue: '交互前先读快照,再决定点哪个' (read snapshot before interacting), and explains that VTable canvas cells are absent from the a11y tree and instead use deterministic geometry. It doesn't explicitly name the alternative vtable_* tools, so it stops short of an explicit routing statement.
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 behavioral burden and does it well: it discloses Pyodide/WASM sandboxing, streaming through PrefabApp, injection of data as globals, and a new sandbox per call. It stops short of error or return-contract details, which keeps it from a 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 long but intentionally structured: lead, code examples, and bullet layout rules. Some repetition exists (data-as-globals appears twice), but the length is justified for a code-generation tool with a custom component model.
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 complex tool with no annotations and no output schema, it covers code patterns, component lookup, reactive state, pipes, charts, layout conventions, and data injection. Missing exact return/error semantics and the undocumented sandbox argument leave a small but real gap.
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?
Because schema description coverage is 0%, the Args section is essential and it defines code as 'Python code that builds a Prefab component tree' and data as values injected as variables. The 'sandbox' arg documented in the description is not in the schema and is disallowed by additionalProperties, a minor mismatch, but the actual parameters are clarified.
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 opening sentence 'Execute Prefab Python code in a sandbox and render the result' names a specific action and resource and matches the tool name. It also disambiguates from siblings by framing the tool as code execution plus rendering. The body further clarifies it produces Prefab component UIs.
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 gives concrete directives such as 'Use the components tool to look up available components' and 'Always use PrefabApp as the outermost context manager'. It also provides explicit layout decision rules, for example 'Prefer Grid when children should have equal or proportional widths' and 'Row does not wrap by default.'
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 safety burden. It explicitly says the operation is a read and adds 'defensive取值' (defensive retrieval), signaling it tolerates missing fields and has no destructive side effects. It does not over-elaborate on error behavior, but for a metadata getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the core purpose and a useful parenthetical, followed by a concrete downstream workflow. Every phrase earns its place and there is no filler.
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 zero-parameter, metadata-only tool with an output schema, the description is complete: it states what is read, what fields matter, and how the agent should use them for later batch operations. Nothing essential is missing.
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 is empty, so there is no parameter burden to compensate for. The description sensibly focuses on what the tool returns rather than parameters.
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 ('读取' / read) and a precise resource: VTable metadata covering scale, frozen rows/columns, and theme. It clearly differentiates this from cell-reading and cell-click tools by emphasizing metadata-oriented, defensive retrieval.
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 gives clear operational guidance: the AI should first fetch rowCount/colCount/frozenRowCount before planning batch reads and scrolling. It stops short of naming explicit alternatives or when-not-to-use cases, so it earns a 4 rather than 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 provided, the description carries the full burden, and it does well: it discloses that space-separated terms are OR-matched, that full details appear automatically for small match sets, that broad searches return a compact listing, and that detail/limit can override this. This gives an agent an accurate mental model of the tool's dynamic behavior beyond what the schema states.
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: purpose first, then matching behavior, then an Args list. The example query 'Card Badge Metric' clarifies OR-matching without extra prose. Every sentence earns its place and the structure is easy to scan.
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 highly complete for a search tool: it explains matching semantics, automatic vs. detail mode, override behavior, and limits. The output schema exists, so explaining return shape is unnecessary. The only completeness gap is the undocumented 'components' parameter, which keeps it from a 5.
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?
Three of the four parameters are well covered in the schema, and the description reinforces them with concrete semantics such as OR-matching, the '≤5 matches' automatic threshold, and the default limit of 8. However, the 'components' parameter has no schema description and is completely absent from the description's Args list, leaving a notable gap at 75% 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 opens with a specific verb and resource: 'Search the Prefab component library.' It then sharpens the purpose by stating the tool is for looking up exact argument names, accepted values, and usage examples before writing component code, and it distinguishes the tool from the skill-level layout/pattern guidance. This is clear enough to differentiate from siblings like generate_prefab_ui.
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 tells the agent when to use this tool: before writing component code, when exact API details are needed. It also contrasts with 'the skill' by saying the skill covers patterns and layout while this tool has API details. The query-matching and automatic detail-mode behavior further set expectations for how broad vs. narrow searches behave.
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 explains the UI behavior ('card with one button per option'), the resulting user message ('as if the user typed it'), and the critical blocking constraint: 'After calling this tool, you MUST stop and wait for the user's response.' This is rich, actionable 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 well-structured and front-loaded: purpose first, then usage guidance, then behavioral details, then the critical wait instruction. Every sentence contributes essential information, and the example makes the interaction concrete without bloating the text.
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 3-parameter tool with no output schema and no annotations, this description is complete: it covers what the tool does, when to use it, what the user sees, how the result arrives, and the required post-call behavior. An agent has everything needed to invoke it correctly.
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 the schema already documents title, prompt, and options clearly. The description adds an illustrative example but not significant new parameter semantics, so it appropriately sits at the baseline 3 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 opens with a specific verb and resource: 'Present the user with a set of options to choose from.' It clearly distinguishes itself from sibling tools by focusing on user choice among discrete alternatives, and the rest of the description reinforces this purpose.
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 says 'Call this tool when you need the user to make a decision between discrete alternatives' and adds a when-not: 'don't ask the user to type their choice in chat when you can present clean, clickable options instead.' This gives the agent clear direction on 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 carries the full burden, and it delivers thoroughly. It discloses that the user will see an approval card with Approve/Reject buttons, that the decision appears as a conversation message in a specified format, and that the agent must stop and wait after calling. This goes well beyond a generic 'request approval' summary.
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 long but every sentence earns its place: it covers purpose, proactive usage, UI behavior, response format, and the stop-and-wait requirement. It is front-loaded with the core purpose and structured so the critical behavioral instruction is prominent. No redundant or filler sentences.
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?
Despite having no output schema, the description fully explains what happens after the call, what the user response will look like, and how to handle both approval and rejection. For a tool whose entire purpose is to pause for human input, this is complete and self-contained.
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 the schema already explains each parameter's purpose, defaults, and nullability. The description adds illustrative examples of the summary text and the resulting user message, but it does not meaningfully extend the schema's parameter semantics. Baseline 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 opens with a specific verb+resource: 'Request human approval before proceeding with an action.' It clearly distinguishes the tool's role by framing it as a proactive confirmation mechanism, not a generic prompt or display tool. This is unmistakably different from sibling tools like `choose` or `ui_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 the tool: 'Call this tool proactively whenever you are about to take a significant or irreversible action.' It also gives a when-not instruction: 'Do NOT wait for the user to ask you to seek approval.' This is strong, actionable usage guidance.
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-MCP MCP server](https://glama.ai/mcp/servers/hooplus1ce/Qa-Automation-MCP/badges/card.svg)](https://glama.ai/mcp/servers/hooplus1ce/Qa-Automation-MCP)

Score Badge

Copy to your README.md:

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

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-MCP'

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