nekoro-browser-mcp

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

No annotations are provided, so the description carries the full burden. The return shape {x, y, w, h, visible, tag, text} is helpful, but the description doesn't disclose behaviors like whether it matches one or many elements, what happens on no match, whether it's read-only, or whether scrolling affects coordinates. The visible field hints at visibility info but nothing is explained.

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

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

The description is a single concise code-like line with zero wasted words, which is efficient. However, it's under-specified rather than truly concise — it communicates a return signature but fails to explain tool purpose and parameters. Efficiency without content doesn't earn a high score.

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

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

For a tool with 2 parameters (1 required), 0% schema coverage, no annotations, and no output schema, the description is severely inadequate. A single code-style return signature with an unexplained tab parameter and no behavioral notes leaves an agent guessing about invocation behavior, edge cases, and return semantics.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters sel and tab. The example shows sel is a CSS selector string (via '".btn"'), which adds minimal value. The tab parameter is entirely unexplained — its type, default, and purpose are unclear, and the description adds nothing about it.

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

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

The description is a code example showing 'box_of(".btn") → {x, y, w, h, visible, tag, text}' rather than a prose statement of what the tool does. It implies the tool returns geometry/visibility data for a CSS selector match, but the purpose is only implied, not stated. It doesn't clearly distinguish from sibling tools like click_selector or find_text.

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

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

No guidance on when to use this tool vs. alternatives. It doesn't mention that it returns page-element geometry, when an agent might need it (e.g., before clicking or scrolling), or that it complements click_selector/click_at_xy. The tab parameter is unexplained.

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

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

No annotations are present, and the description does not disclose any behavioral traits such as side effects, permissions, or limitations. It only states the output format.

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

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

The description is extremely concise, with no wasted words. However, it lacks any structural elements beyond a single sentence, which is acceptable given its brevity.

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

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

The tool has multiple parameters and a specific return type, but the description does not explain how to use them, what the dimensions refer to, or any edge cases. The description is far from complete.

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

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

The schema lists four parameters (tab, scale, format, quality) but the description gives no explanation of their meaning, types, or usage. No semantic information is provided for any parameter.

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

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

The description essentially repeats the function name and return type, providing no additional clarity about the tool's purpose. The name 'capture_screenshot' makes the purpose obvious, but the description is tautological.

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

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

There is no guidance on when to use this tool vs alternatives. No context, prerequisites, or comparison with sibling tools is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description says nothing about side effects, error behavior (e.g., what happens with invalid methods), whether responses are returned or discarded, or whether network/CDP sessions need to be pre-enabled. 'Raw CDP command' implies direct access with minimal validation, but this is more implied than disclosed. For a raw passthrough tool, the behavior (pass-through of method+params) is somewhat self-evident, but error handling and response semantics are unaddressed.

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

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

Single sentence with an inline example achieves maximum information density with zero waste. The example grounds the abstract concept immediately. This is exemplary conciseness—short, self-contained, and instructive.

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

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

Two-parameter tool with 100% schema coverage, no output schema. The description plus schema adequately cover the tool's purpose and params. One gap: for a raw CDP passthrough, the return value behavior (does it return the CDP response?) is unspecified, which matters for such a tool. But given the tool's simplicity and schema coverage, it's nearly complete. A note on response/return behavior would push this to 5.

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

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

Schema coverage is 100%, so the schema documents both parameters (method, params). The description adds meaning via the concrete example showing how they map to a real CDP call (method='Page.navigate', params={'url': '...'}). This example exceeds baseline by illustrating the method-params relationship, but it doesn't explain the 'params' object structure beyond the example. Baseline 3 is appropriate with good schema coverage, slightly elevated by the illustrative example.

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

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

The description clearly states this is a 'Raw CDP command' with a verb (execute/send) and resource (Chrome DevTools Protocol methods). It even provides a concrete example (method='Page.navigate', params={'url': 'https://example.com'}). This distinguishes it from siblings like js (general JS execution) and navigate (high-level navigation). It's slightly less than 5 because it doesn't explicitly name sibling alternatives, but the 'Raw' qualifier and example make the purpose clear.

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

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

The description implies usage context—'Raw CDP command' suggests it's for low-level protocol needs rather than high-level operations—but it doesn't explicitly state when to use this versus alternatives like 'navigate', 'js', or 'network_enable'. The word 'Raw' hints at advanced/low-level use, but there's no explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites like network enablement or tab selection.

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

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

Without annotations, the description carries the transparency burden. It discloses a subtle behavior: for text/index locators, only the first match is returned, and supplying nth causes a permanent error. It also explains the nth prefix behavior. However, it does not mention other potential behaviors like scrolling, waiting, or the effect of the optional tab parameter.

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

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

The description is moderately long but information-dense: examples come first, followed by a clear statement of unified usage and an edge-case warning. Every sentence contributes, with no filler or repetition.

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

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

For a tool with no annotations and no output schema, the description covers the core locator syntax, the unified-entry rationale, and an important error behavior, which is fairly complete. But it omits the tab parameter and does not describe behavior like element-not-found or success/failure responses, leaving some uncertainty.

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

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

The description adds substantial meaning to the loc parameter with a variety of examples and the nth prefix syntax, going far beyond the bare schema. However, the 'tab' parameter is completely undocumented in both schema and description, leaving a gap for an optional but potentially relevant input.

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

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

The description clearly defines the tool as a unified locator-based click ('统一定位点击') and provides concrete syntax examples (css:, text:, index:, xpath:, placeholder:). It explicitly differentiates from sibling tools like click_selector, click_text, and click_index by stating '不用在 click_selector / click_text / click_index 之间挑' (no need to choose among them).

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

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

The description explicitly positions this as the single entry point for all locator-based clicks, telling the agent not to choose among click_selector, click_text, or click_index. It also gives exclusions: the nth prefix only works with css/xpath/placeholder, and using it with text/index will cause a permanent error rather than an unintended click.

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

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

With no annotations present, the description carries the full transparency burden. It discloses the use of CDP, a full click sequence, the isTrusted:true property, and the tab attachment requirement. However, it does not mention coordinate space, scrolling behavior, or potential outcomes like clicks outside the viewport.

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

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

The description is extremely concise, consisting of two short sentences with a concrete example at the front. Every sentence and phrase adds useful information, with no wasted words.

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

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

For a simple click tool with no output schema and no annotations, the description gives the essential behavior and tab handling. It is adequate but incomplete: an agent is left to infer coordinate space, edge cases, and return behavior.

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

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

The schema has 0% description coverage, so the description must compensate. The tab parameter is explicitly explained, and the example click_at_xy(100, 200) maps the first two arguments to x and y. Yet the description does not clarify coordinate units or the coordinate origin.

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

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

The description clearly identifies the action as a CDP-based complete mouse click sequence and uses the example click_at_xy(100, 200) to indicate coordinate-based operation. Although it doesn't explicitly contrast with sibling click tools, the name and example make the purpose unambiguous.

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

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

The only usage guidance is that the optional tab parameter requires an already-attached tab and defaults to the active tab. There is no indication of when to prefer this tool over click_text, click_selector, or other sibling tools, leaving the selection decision largely to the agent.

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

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

With no annotations, the description carries full behavioral disclosure burden. It does communicate that the click uses CDP with isTrusted:true and real coordinates — useful behavioral information. However, it doesn't disclose what 'index' refers to (an element index? a tab index?), whether it requires a real (non-headless) tab given the ensure_real_tab sibling, or what happens on failure. The disclosed CDP/isTrusted behavior is notable value but incomplete.

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

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

The description is a single short line, which is concise. However, the man-page-style suffix '(3)' is unhelpful noise that could confuse an agent. It's efficient but the format is odd and arguably wastes the limited text budget on a non-informative notation rather than useful content.

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

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

This is a moderately complex tool (clicking an element by index across possibly multiple tabs) with no output schema, no annotations, and 0% parameter coverage. The description does not explain the index semantics, tab handling, real-tab requirements, or return behavior. For a tool that performs a real user-visible action, the description is far too thin to guide correct invocation.

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

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

Schema description coverage is 0%, and the description adds no parameter guidance whatsoever. The description does not explain what 'index' means in this context, nor what the optional 'tab' parameter does. With 0% coverage and zero description compensation, the agent cannot determine parameter semantics — this is a critical gap. The description carries no parameter information at all.

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

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

The description states "CDP 真实坐标点击 (isTrusted:true)" — it identifies the intent (real-coordinate click via CDP with isTrusted true). However, the format "click_index(3)" mixes man-page notation confusingly, and it's entirely in Chinese which may not help non-Chinese-speaking agents. It distinguishes from siblings like click_at_xy and click_selector only implicitly via the 'index' parameter, but this isn't stated. Purpose is moderately clear but under-specified.

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

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

No guidance is provided about when to use click_index versus sibling tools like click_selector, click_at_xy, click_text, or hover_index. The description doesn't explain the relationship between index-based clicking and selector/text/coordinate-based alternatives, nor does it mention any prerequisites (like an active real tab, given the sibling ensure_real_tab exists). Usage context must be inferred entirely.

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

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

With no annotations, the description carries the burden. It discloses the key behavioral trait that the backendNodeId is stable across rounds, which is useful. However, it omits important operational details such as prerequisites (e.g., element must exist), failure behavior, or whether it scrolls into view. The disclosure 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.

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

The description is a single, concise sentence that front-loads an example usage. Every word contributes to the meaning without redundancy.

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

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

The tool has only one parameter and no output schema, but the description covers the core mechanism and stability benefit. However, it lacks context on how to obtain the backendNodeId or when to prefer this over sibling tools, and with no annotations there is no safety or side-effect disclosure. The description is adequate for a simple click action but not fully complete.

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

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

The schema only specifies 'ref' as an integer, but the description adds meaningful semantics by indicating that 'ref' is a backendNodeId. This clarifies the parameter's purpose and expected type usage. It does not explain where to obtain the ref, but it goes beyond the raw schema.

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

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

The description clearly states the function: 'click using backendNodeId' (用 backendNodeId 点击). It specifies the resource (backendNodeId) and the verb (click), and the added note about cross-round stability distinguishes it from other click variants like click_selector or click_text.

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

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

The description implies usage when a stable backendNodeId handle is available ('cross-round stable handle'), but it does not explicitly compare to alternatives or state when not to use other tools. There is no direct when-to-use/when-not-to-use guidance, only the mechanism.

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

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

The description says 'CDP 真实坐标点击 (isTrusted:true)' which adds meaningful behavioral context — this uses CDP's real coordinate click mechanism and produces trusted events. However, it doesn't disclose behavior around visibility requirements, element occlusion, or failure modes when the element isn't interactable. With no annotations at all, the burden is on the description, and while it conveys the key behavioral trait (real click vs synthetic), it could go deeper.

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

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

Single compact sentence with a terse 'selector("...")' usage hint front-loaded. Extremely concise with the key behavioral detail (isTrusted:true) emphasized. It's efficient but almost telegraphically brief, using minimal words to convey the core function plus trusted-event detail.

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

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

The tool is a click operation with only 2 params (sel, tab), no output schema, and no annotations. The description names the selector usage pattern and adds the isTrusted detail, but for a 0%-coverage schema it provides no info about the tab parameter semantics, return value, or failure behavior when the selector doesn't match. Given the low schema coverage, the description should compensate more.

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

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

Schema coverage is 0%, meaning the schema properties have no descriptions. The description shows a usage example with the sel parameter and mentions it takes a CSS selector (".btn"), which adds some meaning for sel. However, the second parameter 'tab' is completely undocumented in both schema and description — no mention of what it does, its default, or when it's needed.

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

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

The description states '真实坐标点击' (real coordinate click), using a specific verb (click) on a specific resource (a CSS selector element) and adds the distinctive isTrusted:true trait. It distinguishes this from siblings like click_at_xy (raw coordinates), click_index (positional indexing), and click_text (text-based), though it doesn't explicitly name the alternatives. Purpose is clear but sibling differentiation is implicit rather than stated.

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

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

No guidance on when to use this vs alternatives like click_at_xy, click_index, or click_text. The sibling tools include several other click variants, and there's no indication which scenario warrants this one — e.g., when real trusted events are needed for anti-bot detection or when coordinate clicks fail. Usage context is entirely implied by the name and description.

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

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

The description mentions 'CDP 真实坐标点击 (isTrusted:true)', which adds useful behavioral context about how the click is executed (real CDP coordinates, trusted events). However, no annotations are provided, so the description carries the full burden. It doesn't clarify whether this is destructive, requires a loaded page, or what happens if the text isn't found.

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

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

The description is extremely compact — a single line with an example call and a brief technical qualifier. It's concise without waste, though the lack of elaboration means some needed context is missing.

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

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

For a click tool with 2 params (text required, tab optional) and no annotations or output schema, the description is underspecified. Sibling tools like click_selector, click_at_xy, and click_index suggest multiple click mechanisms exist, and this description doesn't explain when to prefer click_text over those alternatives. No info on error behavior when text isn't found or how it interacts with page loading states.

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

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

Schema description coverage is 0%, so the description must compensate. It documents the 'text' parameter via the example ('置'), but gives no guidance on the 'tab' parameter at all. The example helps clarify text semantics but not tab. This only partially compensates for zero schema coverage.

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

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

The description names a specific verb (click) and a resource (text), and distinguishes it as a CDP real-coordinate click with isTrusted:true. However, 'click_text' is fairly self-explanatory, and the description doesn't differentiate it from sibling click_selector, click_at_xy, or click_index beyond the CDP/trusted technical detail.

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

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

No guidance is provided on when to use this tool versus click_selector, click_at_xy, click_index, or hover. The CDP/trusted qualifier hints at a specific use case, but it's not explicit. There's no mention of when it might fail or when an alternative is more appropriate.

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

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

There are no annotations provided, so the description carries full behavioral disclosure burden. It does well: explains it uses the chrome.tabs.remove extension action, describes the auto-reconnect behavior after closing an active tab (via attach callback syncing active_tab_id), and discloses the ok:false return when no tab is available to close. This is meaningful behavioral context beyond the raw name.

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

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

The description is compact and information-dense: example call, omission default, underlying mechanism, reconnect behavior, and failure mode all in three sentences. It's front-loaded with the purpose and packs details efficiently without waste.

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

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

For a simple 1-param tool with no output schema and no annotations, the description covers purpose, parameter semantics, behavioral side-effects (reconnect after closing active tab), and failure signaling (ok:false). This is reasonably complete for the complexity level.

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

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

Schema coverage is 0% (the tab parameter has no description in the schema), so the description must compensate. It explains the example value (123) and the omission behavior, but doesn't elaborate on parameter constraints (e.g., whether negative/invalid ids produce specific errors). The description provides baseline value but doesn't fully compensate for zero schema coverage.

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

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

The description clearly states the tool closes a specified tab with example usage 'close_tab(123)'. It distinguishes itself from siblings like switch_tab and new_tab by the verb '关掉' (close) + resource (tab). However, it doesn't explicitly differentiate from other tab-related tools beyond the clear purpose.

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

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

The description implies usage context (closing a tab, defaulting to current attached tab if omitted) but provides no explicit when-to-use vs alternatives guidance. It does explain the tab-omission behavior clearly, which is useful context for an optional-parameter tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses the iterative process, partial failure isolation, likely cause (manual tab closure), and return format. It doesn't dive into edge cases like invalid ids, but this is acceptable.

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

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

Two short sentences: the first shows the call signature and intent, the second explains failure tolerance and return. No wasted words.

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

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

For a simple batch tool with no output schema and no annotations, the description covers purpose, behavior, and return structure sufficiently. The failure-isolation note addresses the key operational scenario.

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

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

The schema already describes the tabs array and its provenance from sweep_tabs. The description adds a concrete usage example (close_tabs([1,2,3])), reinforcing the expected input format, which is valuable beyond the schema.

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

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

The description clearly states it batch-closes tabs by iterating over close_tab, distinguishing it from the singular close_tab sibling. It also specifies the return object shape {closed, failed}.

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

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

The description implies batch usage and notes that failure in one tab doesn't affect the rest, but it doesn't explicitly state when to use close_tabs over close_tab. The sibling list includes close_tab, making the distinction inferable.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose key limits (cannot cover beforeunload/opened dialogs) and the injection-timing requirement, which is valuable context. However, it doesn't describe what happens if the dialog mechanism isn't present or the scoping (all tabs vs current tab) behavior, leaving some behavioral ambiguity.

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

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

The description is compact (two sentences) and front-loaded with the core purpose. However, it's dense and mixes implementation detail ('JS 层'), behavioral limits, and alternative-tool guidance in a run-on manner without clear segmentation, making it slightly harder to parse despite being short.

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

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

The tool has 1 undocumented parameter, 0% schema coverage, no output schema, and no annotations. The description explains the mechanism and limitations well but omits the meaning of the 'tab' parameter entirely and provides no return-value or idempotency information. For a fairly niche utility tool with thin structured metadata, the description is partially complete but has clear gaps around the parameter.

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

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

Schema description coverage is 0% and there is 1 parameter ('tab') with no description. The description never mentions the 'tab' parameter at all — it doesn't clarify whether tab targets a specific tab or is optional (0 required params). For a tool with a single undocumented parameter and 0% schema coverage, the description fails to provide necessary parameter semantics.

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

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

The description states it overrides window.alert/confirm/prompt to auto-dismiss at the JS layer. The verb '覆盖...为自动关闭' is reasonably specific, but the tool name (dialog_off) combined with no title leaves purpose somewhat clear yet not richly elaborated.

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

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

The description explicitly notes the injection must happen before the trigger ('需在触发前注入'), identifies what it cannot cover (beforeunload, already-open native dialogs), and points to an alternative tool (get_last_dialog via CDP) for more robust handling. This is genuine usage guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses that events are cached and drained (consuming them on retrieval), which is key behavioral info. However, it doesn't mention whether draining clears the buffer, if events could be lost if not drained in time, or whether invoking this is non-destructive in terms of the underlying browser state. The drain semantics are partially implied but not fully explicit.

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

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

Two concise sentences that are front-loaded with the core purpose (pull cached CDP events) and followed by the return structure. No wasted words. Could arguably merge the return-type detail more smoothly but it's efficient and structured well.

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

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

Given 0 params and no output schema, the description does explain the return shape which is the main missing piece. However, for a stateful 'drain' operation, it could be more complete about buffer semantics (does drain clear the cache? what happens with old events?), rate limits, or whether events persist across invocations. The description tells you what comes back but not the lifecycle guarantees.

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

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

The tool has 0 parameters, and schema coverage is 100% with an empty properties object. The description correctly compensates by explaining what the return value contains, even though there's nothing to explain about inputs. The event structure {method, params, sessionId, tabId} is documented, which adds meaningful information beyond the empty schema.

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

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

The description clearly states the verb (drain/pull) and resource (cached CDP events since last drain). It specifies the return type is a list and describes each event's structure. It doesn't explicitly distinguish from siblings, but the concept of draining buffered events is distinct enough among the sibling tools listed.

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

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

The description implies it's used to retrieve buffered CDP events accumulated since the last drain, but doesn't explicitly state when to use it vs. the cdp tool or other event-related tools. The timing ('since last drain') is clear, but there's no explicit guidance on when this is the right choice over alternatives.

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

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

The description discloses the behavioral trait of auto-navigating to about:blank when the current tab is an internal chrome:// page, and states the return format. Since no annotations are provided, the description carries the safety/disclosure burden. It partially addresses this but doesn't mention side effects (e.g., whether it navigates existing tabs, whether it affects user session/history, or what happens if the tab is already a real page).

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

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

The description is two concise sentences covering purpose, trigger condition, and output. It's compact but covers the key information. Slightly terse but no wasted words.

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

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

The tool is simple (0 params, no output schema), so the description covers the core function. However, it doesn't clarify edge cases like what constitutes an 'internal page', whether the navigation is synchronous, or what the {url, title} represent post-navigation. Adequate for a simple utility but could note more behavioral details.

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

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

With 0 parameters, the description has no parameter semantics to explain. The baseline for 0 params is 4, and the description appropriately explains the tool's behavior and output format despite having no inputs.

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

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

The description clearly states the verb ('ensure'), the resource ('tab'), and the specific behavior (auto-navigate to about:blank when the current tab is an internal chrome:// page). It returns {url, title}. This is specific and distinguishes it from siblings like navigate or new_tab.

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

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

The description implies the use case: for navigating from internal pages to a real page before performing actions. However, it doesn't explicitly state when to use this vs alternatives (e.g., navigate to about:blank directly, or new_tab). Usage context is clear but not contrasted with sibling tools.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only hints at 'openOrReuseTab' semantics but does not explain what happens when a tab already exists, whether it switches focus, creates a new tab, modifies existing tabs, or handles timeouts. This is a significant gap for a tool that likely performs navigation and tab management.

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

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

The description is very brief and front-loaded with an example call, which is good. However, the inclusion of an internal implementation reference ('借鉴 ego-lite 的 browser.openOrReuseTab') adds noise without clarifying behavior for the agent. It earns a middle score because it is short but sacrifices useful information for a niche comment.

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

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

The tool has two parameters, no output schema, and no annotations, yet the description explains almost nothing. It does not mention return values, side effects, or how it interacts with tab state (e.g., whether it can close other tabs). For a navigation-like tool that likely has side effects, this is severely incomplete, especially compared to richer sibling tools like `navigate` or `new_tab`.

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

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

Schema description coverage is 0%, and the description does not elaborate on the meaning of `url` or `timeout`. The URL parameter is obvious, but `timeout` semantics (units, default, what it applies to) are entirely undocumented. With two parameters and zero schema coverage, the description should compensate but does not.

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

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

The description uses the verb 'ensure' with a URL resource, indicating the tool guarantees a tab exists at the given URL. However, it does not explicitly distinguish itself from siblings like `new_tab` or `ensure_real_tab`, relying on the reference to ego-lite's `openOrReuseTab` to suggest reuse-first behavior.

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

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

The description implies reuse-first navigation and notes that callers don't need to pass `reuse=True`, but it provides no explicit guidance on when to use this over `new_tab`, `switch_tab`, or `navigate`. It does not state when not to use it or name alternatives directly.

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

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

With no annotations provided, the description carries the burden but only discloses two traits: helpers are pre-bound and top-level await is allowed. It does not state that running arbitrary code can mutate state, that errors are surfaced in a particular way, or how results are returned. For an execution tool, more behavioral disclosure (e.g., that this runs in the live daemon and can have real side effects) would be warranted.

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

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

Two sentences, zero waste. Every clause earns its place: the execution environment, the helper binding, await support, and a concrete usage example. Front-loaded with the core action first.

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

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

The tool is complex (arbitrary code execution) with no output schema and no annotations, making it a higher-burden case. The description explains what it does and when to use it, but falls short on what the agent should expect regarding return values, error handling, or side effects. It's adequate for a generic escape hatch but could better set expectations for a complex tool.

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

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

Schema description coverage is at 100%, so the schema fully documents the single 'code' parameter. The description adds context about what the code runs in (helpers pre-bound, await allowed), which adds some value, but the baseline 3 is appropriate since the schema already covers the parameter's meaning.

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

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

The description clearly states it runs arbitrary Python in the daemon namespace with helpers pre-bound and top-level await. The verb+resource ('run arbitrary Python') is specific and distinguishes this from the many sibling navigation/scraping tools via its generic escape-hatch nature, though it doesn't explicitly name a sibling alternative.

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

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

The description provides a clear when-to-use signal: 'Use when no single tool fits' and gives an example (multi-step flows in one round trip). This is strong contextual guidance against its many specialized siblings, though it doesn't enumerate explicit when-not-to-use cases or name alternatives.

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

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

No annotations provided, so the description carries the full burden. It discloses the behavioral traits: uses native value setter, dispatches input/change to reach framework onChange handlers, returns ok:false honestly on failure (does not fake success). This is meaningful behavioral context beyond schema.

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

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

Compact and dense, with a worked example up front and failure behavior noted. Slightly dense/technical (Chinese prose) but each sentence earns its place. No wasted words, though formatting could be cleaner.

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

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

For a 3-param mutation tool with no annotations and no output schema, the description covers purpose, success/failure semantics, framework behavior, and fallback path. The 'tab' parameter remains undocumented, which is a genuine gap for a 3-parameter tool. Otherwise quite complete.

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

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

Schema description coverage is 0%, so the description must compensate. It provides an example invocation filling sel='#email' with text='a@b.com', which clarifies sel and text semantics. However, the third parameter 'tab' is not documented at all, and 'sel' selectors' syntax/format is only implied by the example. Partial compensation.

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

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

Clear verb+resource: fills an input element via framework-aware value setting. The description explicitly distinguishes from type_text (which uses Input.insertText and often bypasses framework setters), and mentions click_selector + type_text as the alternative for custom components. Specific and differentiates from siblings.

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

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

Explicitly states when to use this (React/Vue controlled components where type_text fails) and when not to (custom components needing real typing → use click_selector + type_text). Also notes failure conditions (non-input/textarea/contenteditable → ok:false). Strong when/when-not guidance.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It reveals the return structure (list of objects with text/tag/match/w/h) but doesn't disclose behavioral traits: whether it's a read-only operation, whether text must be visible, matching semantics (partial vs exact), what 'tag' contains, or whether results are sorted. The provided schema includes an 'exact' boolean and 'limit', suggesting matching behavior worth explaining.

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

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

The description is a single compact line with an illustrative example and return format. It's efficiently front-loaded as an example invocation. Could arguably add a short sentence of prose, but as-is it wastes no words.

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

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

Given 4 parameters with 0% schema coverage, no output schema, no annotations, and a rich family of text-related sibling tools, the description is under-specified. The return-object shape is shown but fields (tag, match, w, h) are unexplained, and matching semantics (partial vs exact, case sensitivity, visible vs source text) are unclear. The example conveys the core idea but leaves too much to infer for an agent to use this reliably.

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

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

Schema description coverage is 0%, and the description only illustrates usage of 'text'. Three parameters (tab, exact, limit) are entirely unexplained in both the schema and the description. The 'exact' and 'limit' parameters clearly affect behavior (exact matching, result count) but their semantics are undocumented. The description partially compensates via the example but leaves a majority of parameters without meaning.

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

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

The description shows an example call 'find_text("喜欢")' and the return format '[{text, tag, match, w, h}]', which implies this searches for text on the page. However, it never explicitly states 'Searches for text on the current page' — the purpose must be inferred from the example. It doesn't clarify what the returned fields mean or whether this searches visible/source text, nor does it distinguish from siblings like page_text, get_markdown, or wait_selector.

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

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

There is no guidance on when to use this tool versus alternatives. Siblings include page_text, get_markdown, click_text, wait_selector — all text-related tools that could overlap. The description gives no when/when-not conditions, no context about what scenario this tool is best suited for, and no exclusions or alternatives.

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

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

No annotations are provided, and the description carries the full burden of behavioral disclosure. The description doesn't state whether this affects browser state, whether it requires network enablement or navigation first, what format cookies are returned in, or whether it's a read-only operation. For an unannotated tool, this is a critical gap.

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

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

The description is extremely short (one line), which is efficient, but it's under-specified rather than concise. It's merely a code example with no prose explanation. The example demonstrates usage but does not earn its place as a substitute for an actual functional description.

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

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

For a tool with no output schema, no annotations, and a single undocumented parameter, the description must carry significant explanatory weight. It fails to explain return format, cookie scope, or behavioral side effects. Among 45 sibling tools, this description provides almost no differentiation or operational guidance.

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

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

There's a single 'url' parameter with 0% schema description coverage and no documentation in the tool description. The description shows an example URL usage, implying the parameter is the target site, but doesn't clarify edge cases like requiring exact origin matching, whether protocol matters, or whether subdomain-level matching applies. Minimal value added beyond the schema.

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

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

The description is just a usage example ('get_cookies("https://example.com")'), not an actual explanation of what the tool does. It implies retrieving cookies, but there's no verb+resource statement of purpose. The name suggests 'get cookies' but the description provides no semantic expansion beyond the name.

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

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

No guidance is provided about when to use this tool versus alternatives like set_cookie. There's no context about browser session, authentication scenarios, or when cookie retrieval would be appropriate. The description contains zero guidance on tool selection.

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

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

With no annotations provided, the description carries the full burden and does so comprehensively. It discloses the interception mechanism (Page.javascriptDialogOpening), the handling behavior (beforeunload allows, alert/confirm/prompt cancels), the purpose (prevent JS thread freeze), the return structure, and the side effect of clearing after reading. It also notes the limitation that it cannot answer on behalf of the dialog.

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

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

The description is front-loaded with a clear summary line, then adds necessary detail about mechanism, return value, and caveats. It is appropriately sized—every sentence contributes meaningful information without unnecessary fluff. The structure is dense but readable, ideal for AI consumption.

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

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

Given there is no output schema, the description fully specifies the return value structure (dialog = {kind, message, url, defaultPrompt} or None). It also covers the behavioral context of auto-handling and the side effect of clearing after reading. The description is complete for an agent to understand the tool's purpose, behavior, and limitations.

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

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

The tool has zero parameters, so the schema already fully covers parameter semantics. The description does not need to add additional parameter information. Per the rubric, 0 params gets a baseline of 4, and this is appropriate.

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

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

The description explicitly states '取最近一次被扩展自动处置的原生对话框，读后清' (get the most recent native dialog auto-handled by the extension, clear after reading), which clearly identifies the verb (get), resource (last dialog), and unique side effect (clearing after read). It distinguishes itself from sibling tools by focusing on post-hoc observation rather than dialog interaction.

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

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

The description provides clear usage context, stating '仅事后观测，不能代答' (only post-hoc observation, cannot answer on behalf), which is an explicit exclusion. It also explains the auto-handling behavior (beforeunload allows, alert/confirm/prompt cancels) and that dialogs requiring confirm()===true will be unconditionally canceled. While no alternative tool is named, the when-not-to-use is explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention what happens with non-renderable content, how complex layouts are handled, limits on content size, or whether this reads from the rendered DOM vs raw source. The '→' arrow notation hints at a transformation but reveals no behavioral details.

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

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

The description is extremely brief, which is concise, but the brevity comes at the cost of substance. It's much closer to under-specification than to efficient information density. The arrow notation is compact but provides minimal actual guidance.

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

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

For a tool with 3 undocumented parameters, no annotations, and no output schema, the description is severely under-specified. The agent cannot know what parameters to pass, what the output looks like, or how this differs from page_text. This tool needs significantly more documentation to be usable.

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

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

Schema coverage is 0%, and the description mentions no parameters at all. The three parameters (sel, tab, max_chars) are entirely undocumented—the agent has no idea what 'sel' selects, what 'tab' refers to, or how 'max_chars' truncates output. With 0% coverage and no compensating description, this is a significant gap.

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

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

The description states the tool converts page content to Markdown, giving a specific verb+resource ('get_markdown', '页面内容转 Markdown'). However, it's somewhat tautological—the name and description essentially repeat each other, and it doesn't distinguish from sibling tools like page_text or page_html which also retrieve page content in different formats.

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

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

No guidance on when to use this tool vs page_text, page_html, or other content-extraction siblings. The description doesn't explain what makes Markdown output preferable to plain text or HTML in certain scenarios, nor does it mention any exclusions or prerequisites.

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

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

The description provides no behavioral transparency whatsoever. It shows a code example but doesn't explain what the tool does, what the response body contains, how the CDP network response is structured, or any error conditions. No annotations exist to compensate. For a tool with zero described behavior beyond the name itself, this is a complete gap.

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

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

The description is extremely short, but this is under-specification rather than genuine conciseness. A single example without any explanatory prose does not help the agent understand the tool's purpose or usage. There is no front-loaded information that clarifies what the tool accomplishes.

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

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

With no output schema, no annotations, and no parameter documentation, this description is severely incomplete. The tool appears to retrieve a CDP network response body but provides no context on when it's useful, what requests produce response bodies, or what the returned data looks like. For a tool with one undocumented parameter and zero schema coverage, the description fails to fill any gaps.

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

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

Parameter documentation coverage is 0%, and the description adds essentially nothing about the request_id parameter. The example '1234.5' is likely a semicolon rather than a request ID, and even so, it doesn't explain where request IDs come from or how to obtain them. The description fails entirely to explain parameter meaning or provenance.

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

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

The Chinese fragment 'CDP 网络响应体' translates to 'CDP network response body,' which clarifies the general domain but doesn't establish a clear purpose. The name 'get_response_body' combined with this fragment tells the agent it retrieves a network response body, which is somewhat clear, but it doesn't specify what kind of response, from which requests, or how it relates to sibling tools like network_enable or wait_for_network_idle.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing network_enable first, doesn't explain when response bodies become available, and doesn't discuss alternatives. The example without explanation provides no actionable usage direction.

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

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

No annotations are provided, so the description carries full disclosure burden, but it explains nothing about behavior — whether the hover is temporary, whether it triggers tooltips/menus, whether the page scroll is modified, or whether hover state affects subsequent interactions. With zero annotation coverage and no behavioral context, this is a major gap.

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

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

The description is very short — nearly a one-liner — which is concise, but it's under-specified rather than efficiently composed. The code-example style packs minimal information into the space, but the lack of elaboration outweighs the brevity benefit.

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

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

For a tool with 2 parameters, 0% schema description coverage, no output schema, and no annotations, the description is severely inadequate. It neither explains the parameters, the return behavior, nor the interaction semantics. Compare this to sibling interaction tools like click_selector and hover_index, which presumably clarify their behavior.

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

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

Schema description coverage is 0%, and the only hint is the "sel" parameter in the code example, which isn't explained as accepting a selector string. The second parameter (tab) is entirely undocumented in both description and schema. The description fails to 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.

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

The description "hover(".menu") — CSS 选择器悬停" is mostly a code example plus a Chinese phrase meaning "CSS selector hover." It conveys the tool hovers over an element identified by a CSS selector, but the purpose is under-specified — no verb+resource clarity, no mention that it moves the mouse to an element's position. It reads more like a usage snippet than a description.

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

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

No guidance on when to use this tool versus alternatives. Sibling tools include hover_index, click_selector, and find_text, which suggest alternative interaction paths, but the description gives no distinction between hovering by selector vs by index or when hovering is appropriate (e.g., to trigger tooltips/dropdowns before clicking).

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It says it hovers an element but doesn't state whether this requires the page to be loaded, whether it triggers events, whether it scrolls into view first, or how errors are handled (e.g., if the index is out of range). For an action tool with zero annotation coverage, the behavioral details are thin.

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

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

The description is a single terse line, which is efficient and front-loaded with the core action. No wasted words. However, it's arguably under-specified rather than well-condensed — while brief, it sacrifices essential context for brevity.

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

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

As an action tool with 2 params, no annotations, no output schema, and 0% schema coverage, the description must carry substantial load. It explains the core intent but leaves the 'tab' parameter undocumented, doesn't describe preconditions (must call state() first), and offers no error/edge-case context. This is inadequate for a tool that depends on another tool's output.

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

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

Schema description coverage is 0%, so the description must compensate for both params (index, tab). It explains index as '第 N 个元素' (Nth element), which partially maps to that param. But 'tab' is never mentioned at all in the description, leaving its semantics unexplained. With 0% coverage, the description should document both params more thoroughly.

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

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

The description states it hovers the Nth element of a state() list, which gives a specific verb (hover) and resource (state list element). However, it's quite terse and doesn't clarify what 'state()' refers to or how index maps to elements. The purpose is understandable but under-specified relative to siblings like click_index or hover (which likely hover by selector), and it doesn't distinguish itself from those alternatives.

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

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

No guidance is given on when to use this vs alternatives. The '悬停 state() 列表的第 N 个元素' implies it operates on a list returned by state(), but there's no explanation of how this differs from the sibling 'hover' tool, what state() is, or what prerequisites must exist (e.g., must state() have been called first, must the tab be active). No exclusions or when-not-to-use context is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions it returns HTML and is a pure HTTP GET, implying no browser involvement, but doesn't disclose things like redirect handling, status code behavior, error handling, or whether it follows redirects. With zero annotation coverage, this is a meaningful gap.

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

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

Two short sentences in Chinese, front-loaded with an illustrative signature. Every sentence carries meaning; there is no filler. It is appropriately concise, though it could arguably be slightly longer to explain the timeout parameter.

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

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

No output schema, no annotations, and 0% schema description coverage means the description is the only guide. For a 2-param tool with a timeout and return of HTML, it should explain the timeout semantics, possible failures, and how it differs from browser-based page fetching. The current description is too sparse for the agent to select and invoke confidently.

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

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

Schema description coverage is 0%, so the description must compensate for understanding the two parameters. It references the url conceptually in the signature example but does not explain the timeout parameter at all. The agent cannot infer whether timeout is seconds/ms or what the default is.

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

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

The description states a specific verb (GET) and resource (URL) and says it returns HTML strings for static pages/APIs. It distinguishes from siblings somewhat, but the purpose is clear even though it doesn't explicitly contrast with page_html/page_text, which are apparent siblings that also fetch content.

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

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

The description says "用于静态页/API" (for static pages/APIs), giving implied context on when to use. However, it provides no explicit exclusions or alternatives. Given the many content-fetching siblings (page_html, page_text, get_markdown, get_response_body), the description could guide the agent on choosing between raw HTTP GET and browser-based page fetching, but doesn't.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the core lookup behavior (first match, substring match, returns frameId), but does not state whether the operation is read-only, what happens when no iframe matches, or whether it searches the current page's iframes. These are notable gaps for full transparency.

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

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

The description is a single line with an example, front-loaded and free of any filler. Every word contributes to understanding the tool's purpose and usage.

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

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

For a simple one-parameter finder with no output schema, the description covers input meaning and output type. However, it omits no-match behavior and page scope, and the absence of annotations means these details are not supplied elsewhere. The core is present, but edge-case behavior is missing.

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

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

With 0% schema coverage, the description compensates by explaining that url_substr is the substring matched against the iframe URL, and the example 'iframe_target("player")' clarifies expected usage. It lacks details like case sensitivity or matching scope, but for a single string parameter the meaning is sufficiently clear.

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

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

The description clearly states the tool's function: it returns the frameId of the first iframe whose URL contains the provided substring, with a concrete example. This is a specific verb+resource combo with no ambiguity and no sibling overlap.

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

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

The description gives a clear context: use this when you need a frameId for an iframe matching a URL substring, as demonstrated by the example. It does not explicitly mention alternatives or exclusions, but no sibling tool appears to serve the same purpose, so the guidance is adequate.

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

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

With no annotations, the description takes full responsibility for disclosing behavior. It explains evaluation semantics (bare expression vs. script), automatic function wrapping for 'return', how non-serializable values are handled (Infinity/NaN/-0/BigInt), and error behavior (returns ok:false rather than faking success).

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

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

Every sentence contributes value, covering usage, edge cases, and error handling in a compact format. The description is front-loaded with the primary purpose and immediately provides an illustrative example.

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

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

For a JS execution tool, the description covers the core semantics, error handling, and non-standard values. It could gently mention the structure of the successful return value (e.g., ok:true), but given the lack of an output schema, the current detail is largely sufficient.

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

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

Although schema coverage is 0%, the description thoroughly clarifies both parameters: 'code' contains the JavaScript expression/script, and 'tab' defaults to the active tab. It adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool executes JS in the page and returns the completion value, with a concrete example ('document.title'). It is easily distinguishable from sibling tools like click or navigate, which have different purposes.

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

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

Usage context is implied through examples (e.g., bare expression vs. script, tab defaulting to active tab), but there is no explicit guidance on when to choose this over alternatives like cdp or exec_python. The description implies usage but does not provide exclusions or mention alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses almost nothing: no mention of side effects (presumably a read-only list operation), no notification about what '固化' (solidified) means in behavioral terms, no discussion of error conditions or output format. The description is opaque about what happens on invocation.

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

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

The description is extremely short (one line), which is concise. However, it is under-specified rather than deliberately concise — it trades meaning for brevity. Short but opaque. The phrasing '已固化的站点函数 + 载入失败的文件' is cryptic and doesn't earn its place because it fails to convey clear meaning.

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

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

For a tool whose purpose appears to be diagnostic (listing registered site functions and load failures), the description is far too thin. With no output schema and no annotations, the description alone must explain what the listing looks like, what constitutes a site function, and what '固化' (solidified) means operationally. It provides none of this.

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

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

There are zero parameters and schema coverage is 100%, so there is nothing for the description to compensate for. The baseline of 4 for zero-parameter tools applies. The description gives no parameter context, but with no params, no additional semantic value is needed.

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

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

The description is a tautology that essentially restates the name — '已固化的站点函数 + 载入失败的文件' (solidified site functions + files that failed to load). It doesn't clarify what 'site actions' actually are, what listing them accomplishes, or what the return value represents. The verb 'list' implies enumeration, but the resource being enumerated is vague and jargon-heavy.

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

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

No guidance on when to use this tool versus any of the ~48 sibling tools. There's no mention of context in which this would be useful (e.g., debugging site helper registration, checking loaded site functions). The description lacks any how-when-when-not framing.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return format, the meaning of the 'grouped' flag, the mixed-tab pitfall in ungrouped mode, and the field-absence in older extension versions. For a read-only list operation, this is solid transparency even though side effects are not mentioned.

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

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

The description is compact: one sentence for the core return type and fields, one sentence for the critical 'grouped' caveat. Every clause adds distinct value and nothing is wasted.

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

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

There is no output schema or annotations, so the description must explain the return shape itself. It fully specifies the array structure, field names, the 'grouped' flag semantics, and edge cases about old versions. This is complete for a zero-parameter listing tool.

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

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

The tool has zero parameters and an empty schema, so there is nothing to explain. Per guidelines, a no-parameter tool gets a baseline of 4. The description instead enriches the return-value semantics, which is the right focus.

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

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

The description uses a specific verb and resource: 'list_tabs() → nekoro 托管组里的标签' with an explicit return shape [{tabId,url,title,active,attached}]. It clearly distinguishes the scope (managed group tabs) and flags the ungrouped fallback case, avoiding confusion with generic tab listing.

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

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

It gives explicit usage caveats: when 'grouped: False', the list is actually all non-chrome:// tabs and includes user's own tabs, so it should not be used as 'tabs opened by nekoro'. It doesn't name sibling alternatives, but the warning is clear and actionable.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explains that by default it waits for readyState==='complete', and that wait=False returns immediately after Page.navigate is sent. This is meaningful transparency, though it doesn't mention error handling, timeout behavior, or side effects.

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

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

The description is short and front-loaded with an example. However, the inclusion of 'loaded' alongside 'wait' creates ambiguity and slightly undermines clarity. Still, it is efficient overall.

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

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

The tool has 4 parameters and no output schema, so the description should explain return values and edge cases. It covers the core waiting behavior but omits return type, timeout behavior, and the role of the tab parameter. This is a noticeable gap for a navigation tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'wait' parameter semantics (wait=False immediate return) and provides a URL example, but does not describe 'tab' or 'timeout' parameters. The mention of 'loaded' adds confusion and is not in the schema.

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

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

The description clearly states the tool navigates to a URL, with a specific example and explanation of default wait behavior. It distinguishes itself by detailing the waiting semantics, though it doesn't explicitly differentiate from sibling navigation tools like new_tab or http_get.

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

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

Usage is implied: you call navigate to go to a URL. The wait parameter behavior gives context on when to use default vs immediate return, but there is no explicit guidance on when to prefer this over alternatives or any exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'enable CDP network request capture' with no mention of side effects, whether capture must be explicitly disabled later, resource overhead, or whether this affects other tools' behavior. For a tool that likely enables a persistent capture state, this is a significant 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.

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

The description is extremely short (one phrase), which is economical but arguably under-specified rather than appropriately concise. At this length, it verges on tautological—'enable CDP network request capture' doesn't add meaningful context beyond the tool name itself. It's not wasting words, but it's also not earning its place with useful elaboration.

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

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

Given that this tool likely enables a persistent state affecting subsequent network operations, and there is no output schema or annotations, a comprehensive description should explain what happens after enabling, how to verify it worked, and any interaction with sibling network tools (wait_for_network_idle, drain_events). The single-phrase description is inadequate for a state-changing tool with no structured metadata to compensate.

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

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

The tool has 0 parameters, and schema coverage is 100% (trivially, since there are no properties to document). Per the rubric with 0 params, the baseline is 4. No parameter semantics issues exist because there are no parameters to clarify.

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

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

The description '启用 CDP 网络请求捕获' (enable CDP network request capture) states a verb+resource but is quite terse. It identifies the action (enable network capture) but doesn't distinguish it from siblings like wait_for_network_idle, drain_events, or cdp which are network-related tools. The purpose is understandable but thin and lacks differentiation from clearly related sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives. With siblings like wait_for_network_idle, drain_events, and cdp all touching network functionality, the description provides zero context on when enabling CDP network capture is appropriate, what scenarios call for it, or when it should NOT be used. This is a complete absence of usage guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses the main behaviors (open, group, switch, attach) and the reuse behavior, but omits the fallback when reuse=True finds no reusable tab (though the schema mentions it) and does not explain timeout behavior or potential side effects.

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

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

The description is compact and front-loaded with a usage example. It contains no filler and directly explains the key points in two sentences.

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

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

The description covers the core functionality, but given no output schema and low schema coverage, it lacks details about return values and edge cases (e.g., timeout, fallback). For a simple tool, it is adequate but not fully complete.

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

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

Schema coverage is only 33% (only reuse has a description). The description repeats the reuse semantics from the schema and shows a url example, but does not explain the timeout parameter at all. It adds little value beyond the schema for parameter understanding.

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

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

The description clearly states the action (open a new tab) and adds specific behaviors (add to managed group, switch to it, attach). It distinguishes from sibling tools by mentioning the managed group and attach behavior, which are unique to this tool.

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

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

The description implies usage for opening a new tab and explains the reuse=True conditional behavior. However, it does not explicitly contrast with sibling tools like ensure_tab or switch_tab, and lacks explicit when-not-to-use guidance.

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

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 adds one meaningful behavioral detail: if `tab` is not passed, the tool uses the currently active tab. However, it does not disclose other traits such as read-only nature, network behavior, error handling, or side effects, so it is adequate but not rich.

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

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

The description is a single, brief sentence that conveys the tool's core function and the key parameter behavior. Every word adds value—there is no redundancy or fluff, making it an excellent example of concise communication.

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

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

For a simple tool with one optional parameter and no output schema, the description is largely sufficient. It covers the primary use case and the parameter's behavior. It could be more complete by mentioning return type or potential side effects, but such details are not critical for this tool's simplicity.

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

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

The input schema only defines `tab` as an integer with no description. The description compensates by explaining the default behavior when `tab` is omitted (uses the active tab). This adds meaningful context, though it does not explain all possible values or error scenarios. Given the 0% schema coverage, this is a strong contribution.

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

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

The description clearly states the tool returns the complete HTML of a page, using a specific verb and resource. It includes the behavior of the optional `tab` parameter. However, it does not explicitly distinguish itself from similar sibling tools like get_markdown or page_text, 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.

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 compared to alternatives. The description does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate. Usage is only implied by the tool's name and purpose, not explicitly stated.

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

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

The description discloses that omitting 'tab' targets the current active tab, which is a helpful behavioral detail. However, with no annotations provided, it does not mention read-only status, error handling, or behavior with invalid tab IDs, leaving the description to carry a heavier burden than it does.

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

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

The description is extremely concise: a return signature and a default-value note. Every word is purposeful, and the key information is front-loaded.

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

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

For a simple tool with one optional parameter, the description provides the core return shape and a key default. However, it lacks context on how to specify the tab integer (e.g., index or ID) and what happens on invalid input. Given the absence of an output schema and annotations, this is adequate but not fully complete.

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

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

The schema lists 'tab' as an optional integer with no description. The description adds that omitting it targets the active tab, providing meaning beyond the schema. It does not clarify what integer values represent (e.g., tab ID from list_tabs), but for a single parameter, this is partial compensation.

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

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

The description clearly specifies the return value as {title, url}, indicating a tool that retrieves page metadata. It implicitly distinguishes from sibling content-fetching tools like get_markdown or page_text, though it does not explicitly name alternatives.

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

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

No guidance is given about when to use this tool versus siblings. The only usage note is the default behavior of the 'tab' parameter ('tab 不传打当前活动标签'), which addresses invocation but not tool selection.

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

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

No annotations and no disclosure of side effects, authentication, or rate limits. As a read operation, the lack of explicit safety info leaves uncertainty.

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

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

Extremely concise – one sentence that covers the core functionality and the parameter default. No unnecessary words.

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

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

Provides the essential purpose but lacks details about output format, error handling, or edge cases. Given no annotations or output schema, the description is minimally adequate but not comprehensive.

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

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

The description clarifies that the 'tab' parameter is optional and defaults to the active tab, but doesn't explain what the integer represents (index, ID, etc.), leaving ambiguity.

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

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

The description clearly states that the tool returns visible text from the page, distinguishing it from siblings like get_markdown or page_html by explicitly mentioning 'visible text'.

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

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

No guidance on when to use this tool versus alternatives. It only explains the tab parameter default, but doesn't mention scenarios or prerequisites.

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

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

With no annotations, the description fully carries the burden: it discloses modifier bitmask values (Alt=1 Ctrl=2 Meta=4 Shift=8), default tab behavior, virtual key code dispatch for special keys, char event dispatch for printable keys, and the intentional suppression of char events for Ctrl/Meta/Alt combinations. This rich behavioral context goes far beyond a simple 'presses a key' statement.

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

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

The description is compact and packed with actionable information, with usage examples first. The final provenance note ('移植 browser-harness press_key') is not directly useful for operating the tool but is harmless. The semicolon-separated stream is somewhat dense, but every clause contributes technical value.

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

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

Given its simplicity (3 params, no output schema, no annotations), the description covers invocation, targeting, modifiers, and event behavior comprehensively. It does not mention return values or failure modes, but those are likely unobservable or secondary for a key-simulation tool. The tool is fully usable based on the description alone.

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

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

Schema description coverage is 0%, so the description must explain each parameter. It does: key is exemplified with 'Enter' and 'a', tab is an integer targeting a specific tab (defaulting to the active one), and modifiers is an integer bitmask with explicit values. This is a complete and useful interpretation of the otherwise bare schema.

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

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

The description opens with usage examples (press_key("Enter") / press_key("a")) that clearly establish the operation: pressing a key on a page. It also communicates low-level key simulation behavior (virtual key codes, char events) that implies distinction from text-input tools like type_text, but it never explicitly names or contrasts those siblings.

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

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

The description discloses parameter behaviors (tab defaults to active tab, modifier bitmask) and when certain event types are sent, but it does not state when to choose press_key over type_text, fill_input, or click. Usage is implicit via the key-press semantics and modifier examples, yet no explicit alternatives or exclusions are given.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns interactive elements and a stable handle, and that tab defaults to active tab. However, it does not explain whether the tool is read-only, any side effects, or how the selector/max_items parameters affect behavior. It adds some value but leaves significant behavioral gaps.

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

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

The description is extremely concise—two sentences—and front-loads the core purpose and output shape. There is no verbose or redundant content; every word adds value.

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

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

Given three parameters and no output schema, the description is too brief. It doesn't explain the selector or max_items parameters, how the refs relate to other tools, or what the returned objects contain beyond the tuple structure. This leaves critical gaps for effective usage.

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

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

The schema has three parameters but the description only addresses 'tab' (default behavior). It entirely omits 'selector' and 'max_items', so their meaning and usage are unexplained. Since schema description coverage is 0%, the description fails to compensate for the missing parameter documentation.

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

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

The description clearly states the tool's purpose: it returns interactive elements and stable handles (CDP backendNodeId) as a list of {ref, tag, text}. This is specific and distinguishes it from sibling tools like find_text or get_markdown, as it explicitly returns refs meant for subsequent interactions.

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

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

The description provides minimal guidance: it notes the default behavior when 'tab' is not passed (uses current active tab). However, it gives no hints on when to prefer this tool over alternatives like click_selector or find_text, nor any exclusions or preconditions. The usage context is largely implied by the existence of click_ref siblings.

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

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

No annotations are provided, so the description carries full burden of behavioral disclosure. It mentions no restart is needed (a mild positive), but doesn't disclose whether the reload is disruptive to state, whether in-flight operations are affected, whether it's idempotent, or what errors might occur if the file has syntax errors. For a reload operation with zero annotation coverage, this is under-disclosed.

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

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

The description is a single concise sentence. It's efficient with zero waste. However, it doesn't front-load additional useful context beyond the core statement, so it doesn't earn a 5.

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

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

With no output schema and no annotations for a reload operation, the description should explain the side effects and expected outcome. It doesn't describe what happens on success (a confirmation?), what happens if the file fails to load, or whether the reload is scoped to the current agent session. For a developer-reload tool among 40+ siblings, more context is warranted.

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

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

The tool takes 0 parameters, so there are no parameter semantics to elaborate on. The description correctly reflects a parameterless function. With 0 params, the baseline is 4, and no compensation is needed since nothing is missing.

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

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

The description states what the tool does — reloading agent_helpers.py without requiring a daemon restart. However, it's largely a restatement of the name/title and doesn't clarify what agent_helpers.py does or what reloading it accomplishes. A non-expert agent wouldn't know when this matters.

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

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

No guidance is given about when to use this tool or when not to. Among siblings like reload_extension, exec_python, and js, there's no differentiation about whether to use reload vs executing code directly, or whether there are alternatives. No exclusions or prerequisites mentioned.

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

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

With no annotations, the description carries full behavioral disclosure burden. It doesn't state what reloading does to in-memory state, whether it disrupts current automation, if it resets configurations, or what side effects occur. '强制' (force) implies abruptness but no consequences are disclosed.

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

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

The description is a single short sentence, which is efficient. However, the language is Chinese-only without an English counterpart, which may reduce accessibility for agents/prompts written in English. It's concise but possibly under-specified given the lack of behavioral context.

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

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

For a tool with no annotations and no output schema, the description must explain behavior fully. A single phrase '强制重载扩展' does not explain what reloading entails, when it's needed, what the expected outcome is, or what risks exist. Among 40+ sibling tools, more context would help the agent decide when this is the right choice.

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

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

The tool has 0 parameters with 100% schema coverage, so the baseline is 4 for no params. There is nothing to explain about parameters since none exist, and the description doesn't need to compensate for undocumented params.

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

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

The description states '强制重载扩展（自愈用）' (force reload extension for self-healing), which names the verb+resource clearly. However, it's in Chinese while sibling tools have English descriptions, and there's no English equivalent. It distinguishes from siblings like reload_agent_helpers but only vaguely—'self-healing' is a reason, not a clear purpose.

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

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

No guidance on when to use this vs the many sibling tools. '自愈用' (for self-healing) hints at a use case but provides no concrete trigger conditions, no mention of what scenario requires reloading the extension, and no exclusion guidance against alternatives like reload_agent_helpers.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It gives an example but doesn't state whether this triggers scrolling only, whether it waits for visibility, whether it fails if the element isn't found, or whether it has any side effects. Critical behavioral details are absent.

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

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

The description is extremely short, which is arguably concise, but it is under-specified rather than efficiently complete. A useful example is present, which aids comprehension, but the brevity borders on inadequacy given the tool's ambiguity with close sibling tools.

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

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

This tool has 2 parameters (one optional integer tab, one string selector), zero required params, no annotations, and no output schema. Given the ambiguity with scroll_to and scroll_wheel siblings, the description is incomplete. It fails to explain the tool's role relative to its siblings, the behavior of the tab parameter, or expected outcomes.

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

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

Schema description coverage is 0%, meaning the description must compensate. It references a selector in the example but doesn't clarify the format or required syntax of the 'sel' parameter beyond the CSS-like '#target' hint, and says nothing about 'tab'. The description adds only minimal value over the raw schema.

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

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

The description scroll_into_view("#target") — 滚动到可见 is minimal and partially a tautology. It translates roughly to 'scroll to visible' but doesn't clearly state whether this scrolls an element into view, scrolls a container, or what 'visible' means in context. It does show a usage example with a selector, but the distinction from siblings like scroll_to and scroll_wheel is not elaborated.

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

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

No explicit guidance on when to use this tool versus alternatives. Sibling tools scroll_to and scroll_wheel exist, but the description offers no differentiation (e.g., scroll_to targets a selector, scroll_wheel simulates wheel input, while scroll_into_view might assert visibility). The example selector hints at usage but provides no contextual rules.

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

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

No annotations are provided, so the description carries full behavioral burden. It references window.scrollTo but doesn't disclose behaviors like smooth vs instant scrolling, whether 0,0 is top-left origin, units of the coordinates (pixels), or any edge cases. The '(0, 500)' example and the alias to window.scrollTo provide some hint but are thin.

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

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

The description is a single concise sentence with an illustrative example, front-loading the core action. It's appropriately brief for a simple scroll operation, though slightly terse.

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

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

For a tool that mutates the viewport with two undocumented parameters, zero annotations, and no output schema, the description is under-specified. It doesn't define coordinates, origins, or behavior, and with multiple scroll siblings present, it leaves the agent guessing about which operation is appropriate.

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

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

Schema description coverage is 0%, and the description does not meaningfully explain x and y parameters. The example '(0, 500)' hints they are coordinate values, but units (pixels), coordinate origin (top-left), and whether they are relative or absolute are unspecified. The description does not compensate for the zero schema coverage.

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

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

The description says '滚动页面视口到坐标 (window.scrollTo)' (scroll the page viewport to coordinates), which states the purpose with a verb and resource. It refers to window.scrollTo for clarity. However, it doesn't explicitly distinguish from the sibling tools scroll_into_view and scroll_wheel, which are clearly alternative scrolling methods, so differentiation is absent.

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

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

No guidance on when to use this tool versus scroll_into_view (scroll to element) or scroll_wheel (incremental scroll). With multiple scrolling siblings available, there's a notable gap explaining the distinction (absolute-to-coordinates vs element-targeted vs incremental). Usage context is only implied by the example.

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

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

The description notes the fire-and-forget behavior and that it no longer times out after the fix, which is useful behavioral context. With no annotations present, the description carries the burden but only partially covers it — it doesn't disclose the compositor-level side effects (e.g., it bypasses JS event listeners?), whether events are coalesced, or what the return value is.

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

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

The description is brief — two sentences — but the second sentence is a fragment about a past bug fix ('fire-and-forget 修复后...不再超时') which is low-value implementation history rather than usage guidance. The example call is useful but the cryptic phrasing costs efficiency.

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

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

For a 4-param no-schema-coverage tool with no annotations and no output schema, this description is insufficient. It doesn't explain the parameter semantics, scroll direction conventions, coordinate system, or return behavior. The unique CDP aspect is mentioned but the operational details needed to invoke it correctly are largely missing.

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

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

Schema coverage is 0%, so the description must compensate for undocumented parameters. The description shows an example call 'scroll_wheel(0, 500)' but there are 4 parameters (x, y, dx, dy) — it doesn't explain which args the example maps to, what the coordinate semantics are, or what dx/dy mean. The example is ambiguous about whether (0, 500) means x=0, dy=500 or something else. Significant gap for a 4-param tool.

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

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

The description indicates it's a CDP compositor-level mouseWheel event that can penetrate iframe/shadow DOM, distinguishing it from sibling scroll tools like scroll_to and scroll_into_view. It names the underlying mechanism (Input.dispatchMouseEvent) and its unique capability (iframe/shadow DOM penetration). However, it doesn't explicitly say 'scroll the page' in plain terms and leans on technical jargon.

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

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

The description implies this tool should be used when iframe/shadow DOM penetration is needed, implicitly distinguishing it from other scroll tools. However, it doesn't explicitly state when to use it vs alternatives like scroll_to or scroll_into_view, nor does it state when NOT to use it. The 'fire-and-forget' note hints at a behavior difference but provides no clear usage direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description consists solely of a code example and reveals nothing about side effects, persistence, scope, whether cookies are session or permanent, or what happens on error. For a tool that mutates browser state, this is a significant 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.

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

Extremely short (a single line), so it is not verbose, and the example is front-loaded. However, it is under-specified rather than genuinely concise - it substitutes a code sample for an actual description, sacrificing explanatory value for brevity.

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

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

For a 5-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is grossly inadequate. The code example conveys only a fraction of the tool's behavior, leaving the agent to guess about parameters, return values, error cases, and interaction with browser state. There is no explanation of cookie storage semantics or how this ties into the broader browser-control toolset.

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

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

Schema description coverage is 0%, so the description must compensate for explaining the 5 parameters. The example demonstrates 'name', 'value', and 'domain' usage, but does not mention 'url' or 'path'. It adds no formatting, constraints, or interaction semantics beyond what the schema field names already imply.

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

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

The description is just a code example ('set_cookie("token", "abc", domain=".example.com")') rather than a prose statement of what the tool does. It implies the tool sets a cookie, but this is only inferred from the name and example, not explicitly stated. It does not distinguish from related siblings like get_cookies.

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

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

No guidance on when to use this tool versus alternatives. The example shows a use case but there is no explanation of when setting a cookie is appropriate, prerequisites, or when get_cookies or other tools should be used instead.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't explain blocking behavior, whether it's synchronous, what it does during the sleep, whether it processes pending browser events, or any side effects. For an automation tool that pauses execution, this is a significant disclosure gap.

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

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

It is extremely short ('sleep(2)'), which is concise, but the brevity is under-specification rather than efficient communication. There is no front-loaded information problem since there's almost nothing there, but one line cannot carry the required content for a 1-param tool with 0% schema coverage.

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

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

For a simple 1-parameter tool with no annotations and no output schema, the description is severely underwhelming. It doesn't state the effect on the page/browser, whether events are processed during sleep, minimum/maximum reasonable values, or interaction with other wait-type siblings. A single clarifying sentence about blocking behavior and valid ranges would make it adequate.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'seconds' parameter. The parameter is a number with no constraints, no default, no range, and no units clarification (seconds vs milliseconds) in the schema. The description merely echoes 'sleep' and provides no additional meaning about the seconds parameter, such as allowed ranges or precision.

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

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

The description 'sleep(2)' is essentially a restatement of the function signature/name. It provides no natural-language explanation of what the tool does beyond the implied 'sleep for a duration.' This is a tautology—it repeats the name without adding meaning about the verb, resource, or side effects.

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

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

No guidance is given about when to use this tool vs alternatives like wait_for_load, wait_for_network_idle, or drain_events, which are all sibling tools that also involve waiting. The context clearly calls for guidance on timing/waiting scenarios, but the description offers nothing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it mutates any state despite being named 'state', what side effects exist, or how the returned array items are structured/ordered. The return signature hints at read-only behavior but nothing is explicitly disclosed about costs, freshness, or scope of the returned data.

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

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

The description is extremely brief, essentially a one-line signature. It's compact but not informative — underspecification rather than true conciseness. Being short is not itself a virtue when nothing of substance is conveyed.

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

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

For a 3-parameter tool with no annotations, no output schema, and no schema description coverage, the description is grossly inadequate. It should explain the meaning of sel, tab, max_items, describe the output format in plain language, and clarify how this relates to other element-tree/inspection tools among the many siblings.

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

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

Schema description coverage is 0%, and the description provides zero parameter documentation. There are 3 parameters (sel, tab, max_items) and none are explained. The description mentions 'indexed element tree' which may relate to max_items but makes no explicit connection. With 3 undocumented parameters and no compensating description, this is a significant gap.

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

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

The description 'state() → [{index, changed, tag, text, box}] — 索引元素树' uses a cryptic shorthand. The verb is implied ('get' or 'retrieve') rather than stated, and while it mentions returning element tree indexed items, it doesn't clearly state what operation it performs. The Chinese suffix '索引元素树' (indexed element tree) partially clarifies the return object but the overall purpose is conflated with the return signature rather than plainly stated.

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

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

No guidance on when to use this tool versus siblings like page_html, page_text, get_markdown, or find_text. There's no context provided about what scenario calls for inspecting the element tree state, nor any exclusions or alternatives mentioned. The return-type hint suggests it's an element tree inspection tool but there's no explicit usage direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the key safety behavior that by default it only reports and does not close tabs. However, it does not explain what happens when dry_run is false, any destructive potential, or other side effects. This is useful but incomplete for a tool that can likely close tabs.

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

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

The description is a single, concise sentence that front-loads the core purpose and emphasizes the critical default safety behavior with bold text. Every element earns its place with no redundancy or unnecessary detail.

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

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

For a simple tool with one optional parameter and no output schema, the description adequately covers the primary purpose and the key behavioral default. It does not specify the output format or define what makes a tab 'cleanable', but these are less critical given the tool's simplicity. The description is sufficient to understand the tool's role and main mode of operation.

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

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

The schema has one parameter (dry_run) with no description coverage (0%). The description's mention of "默认只报不关" directly informs the default behavior of dry_run, implying that setting dry_run=false would enable closing. This provides meaningful context for the parameter beyond the schema. It does not fully spell out the exact mapping, but it is sufficient for a single boolean parameter.

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

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

The description clearly states the tool's function: listing tabs that are candidates for cleanup. The verb "列出" (list) and the specific resource "可清理的标签候选" (cleanable tab candidates) make the purpose distinct from siblings like close_tabs and list_tabs. It also notes the default behavior, further clarifying what the tool does.

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

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

The description implies a usage context (listing cleanup candidates before potentially closing tabs) but does not explicitly state when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when not to use it. The phrase "默认只报不关" suggests it's a safe first step, but this is not directly tied to a recommended workflow.

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

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

No annotations are provided, so the description carries the full burden. It discloses the attach-if-not-attached behavior, which is useful, but doesn't describe what happens to the currently active tab, whether the switch is reversible, what the return/state looks like, or any failure modes (e.g., invalid tab_id). For a state-mutating navigation tool with zero annotations, this is a significant gap.

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

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

The description is compact — a single concise sentence with embedded example. It's front-loaded with the verb and resource. No wasted words, though it could arguably be slightly more explanatory without becoming bloated.

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

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

This is a state-mutating tool with no annotations and no output schema. The description only hints at the attach side-effect. It doesn't explain how tab_id maps to tool state, whether the switch persists, what happens after switching, or interaction with list_tabs. For an agent needing to correctly sequence operations, this is incomplete.

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

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

The description shows a concrete example (switch_tab(123)) which implies tab_id is the target tab identifier. However, with 0% schema description coverage, the description must compensate for the lone tab_id parameter. It doesn't explain how to obtain a valid tab_id (presumably from list_tabs), which is a missed opportunity though the example helps.

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

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

The description states the verb (switch) and resource (tab) with a concrete example and side-effect ('未 attach 则先 attach' — if not attached, attach first). It's clear it switches subsequent commands to a given tab. However, it doesn't differentiate itself strongly from siblings like new_tab, close_tab, ensure_real_tab, though the purpose is specific enough to be understood.

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

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

The description implies usage context — switching subsequent commands to a target tab, with auto-attach behavior. But it doesn't explicitly state when to use this vs alternatives or any exclusions. The sibling context (new_tab, list_tabs) suggests complementary tools, but no explicit when/when-not guidance is given.

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

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

With no annotations, the description must carry the behavioral burden. It discloses the mechanism (CDP Input.insertText) and the active-tab default. However, it does not explain what element receives the text, whether key events are fired, or how focus is handled, leaving meaningful behavioral ambiguity.

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

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

The description is compact and front-loaded with a concrete example, which makes it easy to scan. It wastes no words, though the mixed Chinese/English formatting and missing clear parameters explanations slightly reduce readability.

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

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

Given the low complexity (2 params, no output schema), the description is somewhat adequate, but the large sibling set includes overlapping tools like fill_input and press_key. The description fails to explain where this low-level CDP primitive fits, what happens with no focused element, and let alone return values or side effects.

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

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

Schema coverage is 0%, so the description is responsible for explaining the parameters. It explains that 'tab' targets a label and defaults to the active tab if omitted, and the example implies 'text' is the string to type. However, it doesn't specify the type/format for tab, how to identify the tab, or any constraints on text.

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

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

The description clearly indicates the tool performs text insertion by naming 'CDP Input.insertText' and showing an example call 'type_text("hello")'. The verb 'type_text' and the CDP reference distinguish it from higher-level tools like fill_input, though it doesn't explicitly compare with siblings.

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

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

The description mentions that omitting the 'tab' parameter types into the current active tab, giving minimal context. However, it provides no guidance on when to prefer type_text over sibling tools such as fill_input, press_key, or click, and no exclusions or alternatives are named.

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

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

With no annotations provided, the description fully carries the burden of behavioral clarity. It explicitly discloses the CDP mechanism, event triggering, path requirements, failure conditions (file not found, element not found, non-file input) with ok:false, and scoping to the current attached tab. This is exceptionally transparent.

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

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

The description is compact and front-loaded with an example, followed by necessary technical details. Every sentence provides useful information — mechanism, parameter types, error behavior, and scope — without excess. It is well-structured and efficient.

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

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

For a 2-parameter tool with no output schema or annotations, the description covers usage, constraints, failure cases, and environment context. The only gap is that it does not explicitly describe the success return format (only mentions ok:false on failures), but it implies ok:true on success, which is sufficient for most use cases.

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

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

Schema description coverage is only 50% (path has a description, sel does not). The description compensates by giving a usage example for sel, explicitly stating path can be a single str or list, requiring absolute paths, and explaining that nodeId is resolved via query_selector. It adds meaning beyond the schema, though sel semantics are inferred rather than explicitly defined.

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

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

The description clearly states the tool's function: '给文件输入框设文件' (set file on a file input). It provides a concrete usage example and specifies the underlying CDP method (DOM.setFileInputFiles), distinguishing it from sibling tools like fill_input or type_text that handle text inputs.

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

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

The description implies the tool is for file input elements and explains behavior (triggers change event, requires absolute paths, fails on non-file inputs). It gives clear context but does not explicitly exclude alternatives or mention when not to use it, so a perfect score is not warranted.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool waits for specific events, but does not explain timeout behavior, return values, or potential side effects. The mechanism is partially transparent but leaves important behavioral aspects unspecified.

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

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

The description is a single concise sentence with a usage example, front-loading the tool's name and core purpose. No unnecessary information wastes the reader's attention.

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

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

For a simple wait tool, the description conveys the core purpose and mechanism, but lacks details on return values, failure handling, and relationship to sibling tools. With many similar wait tools present, additional context would improve completeness, but the current level is minimally adequate.

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

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

The schema provides no description for the timeout parameter (0% coverage), and the description only shows an example call with 30, implying it is a timeout value. However, units (seconds vs milliseconds) and default behavior are not clarified, adding limited meaning beyond the schema.

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

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

The description clearly states the tool waits for download completion after triggering a download, and specifies the underlying events (downloadWillBegin/Progress). This distinguishes it from sibling wait tools like wait_for_load and wait_for_network_idle.

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

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

The description implies usage ('after clicking download') but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. It offers no guidance on choosing between this and other wait tools.

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

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

Given no annotations, the description must disclose behavior. It mentions polling and 'no listener leaks', which is a useful implementation detail. However, it omits timeout behavior (e.g., does it throw or return false?), error handling, and return value, leaving gaps in predictability.

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

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

The description is extremely concise and front-loaded with an example usage. It avoids fluff, but the structure is a single line with mixed language and minimal formatting. It could be improved with bullet points, but it is efficient and gets the point across.

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

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

For a simple polling tool, the description covers the core action (polling readyState) and a key behavioral trait (no listener leaks). However, it lacks details on timeout semantics, what readyState value is targeted, and what the function returns. With no annotations and no output schema, more completeness would be beneficial for an agent.

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

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

The description explains the 'tab' parameter's default behavior ('if not passed, waits for current active tab'), adding value beyond the schema. However, the 'timeout' parameter is completely undocumented, and schema coverage is 0%. The description only partially compensates for the lack of schema descriptions.

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

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

The description clearly states the tool polls document.readyState, implying it waits for page load. This distinguishes it from sibling tools like wait_for_download (downloads) and wait_for_network_idle (network). However, it does not explicitly state the final readyState condition (e.g., 'complete'), leaving slight ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios where waiting for document.readyState is preferable, nor any exclusion criteria. Only a minor note about tab default behavior, which is parameter-related, not usage context.

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

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

No annotations are provided, so the description carries full burden. It discloses a critical behavioral trait: Network events from OTHER attached tabs also enter the global buffer and, if not filtered, can keep pushing the idle window open indefinitely. It also clarifies the scope is only active_tab_id events. This is genuinely valuable operational context. It doesn't mention failures (what happens on timeout) or return value, though.

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

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

Two compact sentences with an example prefix, highly front-loaded. No filler. The second sentence is technically dense but earns its place by disclosing a critical edge case. Slightly dense for non-native readers but efficient overall.

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

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

For a simple 2-param tool with no output schema, it covers the key operational concerns: scope (active tab), semantics (idle time), and the cross-tab pitfall. However, it omits the timeout behavior (what happens if timeout expires before idle — error? returns early?), which an agent will need to know. Also doesn't clarify whether it's a network call-triggering operation (needs network_enable). For a tool sitting among 40 siblings, this could be richer, but it's adequate for the simplicity level.

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

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

Schema coverage is 0%, so description must compensate for parameters. The example call 'wait_for_network_idle(0.5, 15)' effectively implies idle_time=0.5s and timeout=15s (order of positional args), giving the agent intuitive understanding of both parameters' meanings and units without needing to read the schema. This is strong compensation for the zero coverage.

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

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

Description states the verb+resource clearly: wait for Network requests to be idle for a specified time in the active tab. It provides a concrete usage example and the core mechanism. However, it doesn't clearly differentiate from siblings like wait_for_load, sleep, or drain_events — the closest behavioral sibling (drain_events, wait_for_load) isn't named, so some differentiation is missing.

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

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

The description explains WHEN it's appropriate (after navigation/network activity to let requests settle) implicitly through the idle semantics, and importantly warns about background tabs that poll/SSE keeping idle window perpetual. However, it doesn't explicitly state when to prefer this over alternatives like sleep or wait_for_load, nor when NOT to use it (e.g., for navigation completion use wait_for_load).

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

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

With no annotations provided, the description carries the full burden of disclosure. It does not state what happens on timeout (throws vs returns), whether the tool polls or blocks, or what side effects occur. As a waiting/mutation-vs-read tool, this is a significant 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.

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

The description is extremely short—essentially a single example line plus a Chinese phrase. It's brief, which is a virtue, but the brevity leaves critical details out. It's not bloated, but it under-delivers on substance.

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

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

A 4-parameter waiting tool with no annotations, no output schema, and 0% schema description coverage needs more explanation. The description fails to cover state options, timeout default/units, tab behavior, and error handling. The sibling context (wait_for_load, sleep) suggests multiple wait tools exist, increasing the need for differentiation that is absent.

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

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

Schema description coverage is 0%, so the description must compensate. It only hints at 'sel' and 'state' via the example ('.modal', 'visible'), but does not document 'tab' or 'timeout' at all. The example reveals some semantics for two parameters but leaves half the parameters undocumented.

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

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

The description gives an example call and a Chinese explanation '等待元素状态' (wait for element state). This conveys that the tool waits for a selector to reach a specified state, but it lacks a formal English purpose statement. The example partially clarifies intent but is somewhat unclear about what states are supported and what the return value is.

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

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

There is no guidance on when to use this tool versus alternatives like wait_for_load or sleep. The example shows a pattern but doesn't explain scenarios where waiting on a selector state is preferred over other wait mechanisms, nor does it exclude alternatives.

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