Server Quality Checklist

Tool Scores

• get_textA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description itself must disclose behavior. It does state the read action and default selector, but does not mention whether the operation waits for the element, what happens on no match, or what the returned value looks like beyond being the innerText.

  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 captures the core behavior and the default case with zero redundancy. It is appropriately compact for such a simple 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 simple optional-parameter read tool, the description covers the essential behavior and default. It relies on the schema for note/pageId semantics, which is acceptable given 100% schema coverage, though return-value details are not explicitly stated.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds only the default-body behavior for selector, which the schema also already states, providing no meaningful extra semantics.

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

  Purpose5/5

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

  Description clearly states the tool reads innerText of the element matching a CSS selector, defaulting to the whole body. This precisely distinguishes it from siblings like get_screenshot, get_dom_snapshot, and get_console.

  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 get_dom_snapshot or get_console. The description only explains mechanics, not selection criteria or context.

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

• clickA
  3.8/5.0
  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 adds useful details: it calls scrollIntoView first and returns an error if the element is not found. It does not mention success return values or multiple-match behavior, but the disclosed behaviors add real value beyond the action itself.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence that conveys the core action, key pre-behavior, and failure mode with 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 simple click tool, the description covers the essential behavior, preprocessing, and error case. It could be more complete by noting what happens with multiple matching elements or what a successful call returns, but it is sufficiently clear for an agent to use correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description only restates the selector concept and adds no parameter-specific guidance beyond that.

  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: find an element via CSS selector and trigger click(). It also distinguishes itself from sibling tools like hover, focus, and type by describing the click action explicitly.

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

  Usage Guidelines2/5

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

  The description does not state when to use this tool versus alternatives like eval_js, hover, or type. It only implies usage through the word 'click', but provides no explicit context, exclusions, or alternative routing.

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

• scroll_toA
  3.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It does disclose the key behaviors: finding by CSS selector, using scrollIntoView, centering in the visible area, and returning position info. It omits potential side effects or return structure details, but for a scroll tool the disclosed behavior is reasonably 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?

  One dense, front-loaded sentence conveys the action method, targeting mechanism, and return value without any wasted words. Every clause contributes useful information.

  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 one required parameter, and a fully documented schema. The description covers the core operation and return value, but since there is no output schema, the vague 'position info' could be more precise about what the returned data actually contains.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3 and the description need not repeat parameter details. The description adds no real parameter-level meaning beyond the schema; mentioning the CSS selector simply restates what the schema already says.

  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 (scroll to center via scrollIntoView), a specific resource (element found by CSS selector), and a concrete output (post-scroll position info). This clearly distinguishes it from sibling tools like click, hover, or get_screenshot.

  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 the tool operates but gives no guidance on when to use it versus alternatives or when not to use it. An agent gets no explicit context about conditions that should trigger scroll_to instead of eval_js or other navigation-related approaches.

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

• typeA
  3.8/5.0
  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 does disclose meaningful behavior: finds by CSS selector, focuses, writes text, dispatches input/change events, and supports contenteditable. It could add error-handling or waiting behavior, but the core side effects are clearly stated.

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

  Conciseness5/5

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

  The description is a single compact sentence with no filler. Every clause adds useful information: selector targeting, focusing, text writing, event dispatch, and contenteditable compatibility.

  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 focused typing tool, the description is largely complete: the targeting mechanism, action, and event behavior are all disclosed, and the schema covers parameters. It omits explicit when-to-use guidance and return/error details, but these are not critical for correct invocation.

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

  Parameters3/5

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

  The input schema already documents all four parameters with 100% coverage. The description restates the CSS selector and text concepts but does not add new parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description identifies the action (write text), the target (input element or contenteditable), and the mechanism (CSS selector, focus, then dispatch events). It is clear about what the tool does, though it does not explicitly differentiate it from sibling tools like focus or click.

  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 that this is for editable elements and contenteditable targets, but it does not explicitly state when to use type instead of focus, click, or hover. Usage context is inferable rather than directly guided.

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

• eval_jsA
  4/5.0
  Behavior4/5

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

  无 annotations，描述承担全部行为披露责任。它详细说明了自动选中页面、返回序列化结果、支持 await 与多语句、末句自动 return 或显式 return 等执行语义，并逐个定义了 9 个辅助函数的行为。但未说明 JS 抛错时的处理、超时后的表现，也未提示执行任意 JS 可能带来的页面副作用。

  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?

  长句但信息密度极高，从目的说明、执行语义到辅助函数清单，几乎无冗余，且核心目的前置。不过辅助函数以逗号连排成长句，缺少分项层级，可读性略受影响；在如此高复杂度的工具下篇幅总体合理。

  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?

  工具复杂度高（任意 JS 执行、9 个辅助函数、4 个参数），且无 annotations 也无 output schema。描述覆盖了执行语义和辅助函数 API，但未说明返回值封装结构（仅提"序列化结果"）、JS 异常与超时行为，也没有副作用警告——对高风险 eval 工具而言这些都是明显缺口。

  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 覆盖率为 100%，基线为 3；但描述为 code 参数补充了大量超出 schema（仅"要执行的 JS 代码"）的语义：await/多语句规则、自动 return 行为、全部辅助函数的签名与返回值（如 $frame 返回 {$,$$,$deep,$$deep,document,window}），并对 pageId 省略时的自动选中行为做了补充，明显高于基线。

  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?

  描述以明确的动词+资源开篇："在指定页面执行任意 JavaScript 并返回序列化结果"，准确说明工具做什么。与兄弟工具（click、type、get_text 等）形成清晰区分——这是唯一执行任意脚本的工具，并补充了页面自动选中规则，无歧义、非同义反复。

  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?

  通过预置辅助函数（$wait、$deep、$frame 等）隐含了典型使用场景，schema 中 pageId 也说明可从 list_pages 获取。但描述没有明确说明何时应使用 eval_js 而非 click/get_text 等替代工具，也没有排除条件（如简单交互优先用专用工具），依赖智能体自行推断。

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

• focusA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry behavioral information. It discloses the mechanism (CSS selector) and the exact events fired (focus and focusin). It could mention behavior on missing or hidden elements, but for a simple focus operation this is reasonably 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 one efficient sentence that front-loads the action and purpose. Every part earns its place with no repetition or filler.

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

  Completeness4/5

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

  This is a low-complexity tool with full schema coverage and no output schema, so the description is largely sufficient. A minor gap is the lack of error behavior or visibility requirements, but these are not critical for basic usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond confirming the selector is a CSS selector; it does not elaborate on note or pageId semantics.

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

  Purpose5/5

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

  The description specifies a concrete action: finding an element via CSS selector and focusing it, and even names the events triggered (focus + focusin). This clearly distinguishes it from sibling tools like click, type, and hover.

  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 a clear use context: place focus into an input before typing. It does not explicitly name alternatives or exclusions, but the intended scenario is clear enough for an agent to select this tool appropriately.

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

• hoverA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses that events are synthetic (派发 mouseover/mouseenter) and that scrollIntoView happens first, both non-obvious behaviors an agent needs. It does not mention failure/timeout behavior, so it is not perfect.

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

  Conciseness5/5

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

  The description is a single compact sentence that front-loads the action, event behavior, use case, and side effect. Every phrase contributes meaning and there is no redundant wording.

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

  Completeness4/5

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

  For a simple action tool with one required parameter, no annotations, and no output schema, the description gives purpose, mechanism, and the critical scrollIntoView side effect. It omits return-value or post-hover waiting details, but those are not essential for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents selector, pageId, and note. The description adds little beyond framing selector as the lookup mechanism, which is below the threshold for extra credit but still consistent with schema.

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

  Purpose5/5

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

  The description states a specific verb and resource: find an element via CSS selector and dispatch mouseover/mouseenter events. It also names the intended effect (triggering menus/tooltips), which clearly distinguishes it from sibling tools like click, focus, and scroll_to.

  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 use cases—'可触发菜单、tooltip 等悬停行为'—so an agent can infer when hover is the right tool. It does not explicitly contrast with click or state when not to use it, but the context is clear enough for selection.

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

• wait_forA
  4.2/5.0
  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 polling interval (200ms), timeout error behavior, the mutual exclusivity of selector/code, and how absent=true changes the condition. This is substantial operational context for a waiting primitive.

  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 sentences, each earning its place: the purpose and use case, the two condition modes, then timeout and polling details. Information is front-loaded and there is zero filler or repetition of schema content.

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

  Completeness4/5

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

  Given no annotations and no output schema, the description is nearly complete for a wait tool: it explains what, when, how, and failure behavior. Minor gaps are the undefined return value and unspecified behavior if both selector and code are supplied, but these are low-stakes for a synchronization tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is already clearly documented. The description adds value by explaining the mutual-exclusion rule and the polling cadence, but it does not add per-parameter meaning beyond the schema—hence the 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 states a specific verb and resource: polling/waiting on the page until a condition holds before returning. It clearly distinguishes itself from imperative siblings like click, type, or eval_js by framing the tool as a synchronization/readiness check.

  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 opening sentence gives a concrete use case—avoiding operations before SPA async rendering finishes—which tells an agent when to reach for this tool. It does not explicitly name alternatives or exclusion cases, but the context is specific enough to guide selection.

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

• list_pagesA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It clarifies the read-only nature of the operation, the scope of 'currently connected' pages, and the exact data returned. For a simple listing tool, this is sufficient transparency, though it does not explicitly state that no side effects occur.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the action, scope, and returned fields without any fluff. Every part of the sentence carries meaningful information.

  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 listing tool with no output schema, the description is complete: it identifies what will be listed, the scope of the listing, and the exact fields included. An agent has enough information to invoke the tool correctly and interpret its result.

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

  Parameters4/5

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

  The tool has zero parameters and the schema confirms this with an empty properties object. With no parameters to document, the description does not need to add parameter-level detail, satisfying the baseline for parameterless tools.

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

  Purpose5/5

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

  The description clearly states the verb '列出' (list), the resource (all browser pages currently connected to web-bridge-mcp via client.js), and the exact output fields (pageId, title, URL, connection time). This makes it easy for an agent to distinguish from the sibling interaction tools.

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

  Usage Guidelines3/5

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

  The description implies the primary use case: obtaining pageId and connection status before interacting with browser pages through sibling tools. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions, so usage guidance remains implied rather than stated.

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

• get_consoleA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that client.js automatically captures and reports console output, that `limit` defaults to 50, and that the response includes a trailing `ts` for incremental polling. It does not explicitly declare the operation as read-only, but the verb '读取' and lack of mutation language make that reasonably clear.

  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 efficient sentences. The first states the core purpose, and the second packs parameter behavior, the incremental polling mechanism, and the intended use case without fluff.

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

  Completeness4/5

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

  The description explains what the tool returns and how to iterate with the trailing timestamp, which is essential since there is no output schema. It does not explicitly cover multi-page behavior for `pageId` or exact response formatting, but the schema covers `pageId` and the sibling `list_pages` provides context.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the cursor protocol: the returned `ts` can be passed as the next `since`, which is more informative than the schema's terse '配合返回值末尾的 ts 使用'.

  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: read recent console output and uncaught exceptions. This resource is unique among the sibling tools, so there is no ambiguity with DOM, navigation, or interaction tools.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: incremental log fetching with a `since` timestamp and using the returned `ts` as the next cursor to distinguish logs before and after code changes. It does not explicitly name alternatives or when-not-to-use conditions, so it falls short of a 5.

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

• get_dom_snapshotA
  4.4/5.0
  Behavior4/5

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

  无注解，描述承担了行为披露责任。说明这是纯文本操作、无需授权，只输出可见节点，且穿 shadow DOM，这补充了安全性和执行行为。虽然未讨论 maxNodes/depth 截断或返回失败情况，但关键行为已明确。

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

  Conciseness5/5

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

  两句话紧凑完成功能说明、输出内容说明、适用场景和替代工具路由，信息密度高且无冗余。关键行为前置，替代方案收尾，结构清晰。

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

  Completeness4/5

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

  无输出 schema，描述说明了输出内容（每行几何、样式、文本），无注解时也覆盖了授权和只读性。5 个参数中必需项在 schema 中已有定义，整体对调用该工具所需上下文已足够；仅缺少对截断或 selector 无效时的行为说明。

  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 描述覆盖率为 100%，参数本身在 schema 中已有完整说明。描述没有额外深化参数语义，但也不构成负担，按 baseline 3 评分合理。

  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?

  描述明确说明对指定元素子树生成「虚拟截图」，包含几何、样式、文本和 shadow DOM 穿透，动词和资源具体。与 get_screenshot 的差异通过「需要真实渲染像素时再用 get_screenshot」直接点出，能清晰区别于兄弟工具。

  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?

  描述明确给出使用场景：验证颜色、布局、定位的首选；并明确列出何时应改用 get_screenshot（canvas 内容、图片、遮挡观感）。提供了 when-to-use 和 when-not-to-use 的清晰指引。

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

• get_guideA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses the return value (SKILL.md full text), the lack of a restart requirement, and the dynamic refresh on re-call. It does not explicitly mention side effects or output size, but for a read-only guide fetch these are minor omissions.

  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 primary purpose is front-loaded and the parenthetical content list tells the agent exactly what the guide covers. The usage advice and refresh behavior are packed efficiently into the second sentence.

  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, no-output-schema tool, the description tells the agent what it returns, what the guide contains, when to call it, and when to re-call it after updates. Nothing required to invoke this 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 100% schema coverage, so there is nothing for the description to add beyond the schema. The baseline of 4 applies because parameter semantics are fully determined by the empty input schema.

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

  Purpose5/5

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

  The description opens with the verb '返回' (returns) and a specific resource: web-bridge-mcp 的完整使用指南 (full SKILL.md). It lists concrete contents such as workflows, eval_js syntax, preset functions, and troubleshooting, which makes it easy to distinguish from the sibling browser-automation tools.

  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 recommends calling this tool before first use of the MCP's tools, and states that after the guide file is updated, calling again returns the latest version without a restart. This is a clear when-to-use condition, and no sibling tool competes for this purpose.

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

• get_screenshotA
  4.9/5.0
  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 thoroughly explains the authorization prompt, one-time approval per page lifecycle, re-authorization after refresh, selector deep-query behavior through shadow DOM, and timeout implications.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place: core function, authorization side-effect, selector behavior, and alternative tool guidance. It is front-loaded with the most important information.

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

  Completeness5/5

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

  The description is complete for a screenshot tool with 4 parameters and no output schema. It covers purpose, side effects, usage conditions, selector semantics, timeout behavior, and alternative tool routing. 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds useful context beyond the schema, such as selector cropping behavior and why timeoutMs matters on first call, elevating it slightly.

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

  Purpose5/5

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

  The description clearly identifies the tool's specific function: capturing real rendered pixels via getDisplayMedia and returning an image. It also distinguishes itself from get_dom_snapshot, making the tool's unique niche immediately understandable.

  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 prefer get_dom_snapshot (color/layout/position verification via text) and when to use this tool (real pixel needs like canvas, images, occlusion). This provides clear routing guidance relative to siblings.

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