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

With no annotations, the description carries the full behavioral burden, and it does disclose meaningful traits: the operation is idempotent, it verifies state, and it avoids blind toggling. It omits what verification returns, how mismatches or missing elements are handled, and whether failures are surfaced as errors.

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 with no wasted words. The core purpose is front-loaded, and the behavioral caveat follows immediately.

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 six parameters, a nested target object, no annotations, and no output schema, the description is too thin. It should explain return/verification behavior and failure modes, and ideally clarify selector targeting or precedence, but it covers only the core idempotency idea.

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%, and the description adds no parameter-level meaning. The roles of `target`, `checked`, `timeoutMs`, and the selector/target precedence are left to the schema, which itself leaves the nested `target` object largely 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 states a specific verb and resource (set checkbox/radio state) and adds a distinguishing behavioral property (idempotent and verified). It implicitly separates the tool from `wb_click` by clarifying it does not blindly toggle, though it does not name sibling 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?

Usage is implied by 'Set checkbox/radio state', which tells the agent the tool is for checkboxes and radios rather than generic clicking. However, there is no explicit guidance on when to choose this over `wb_click` or `wb_select`, and no exclusion or prerequisite information.

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 disclosure burden and covers only fragments: expect verifies the result, and auto-follow is gated on opener evidence. It says nothing about actionability waiting, what happens if the target is ambiguous or missing (notably, zero parameters are required), flakiness/retry behavior, or the return value.

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

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

Four short sentences, front-loaded with the action and its uniqueness constraint. Dense but not padded, though the phrasing is telegraphic enough that a few clauses read as unexplained jargon.

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 9-parameter tool with nested target and expect objects, no annotations, and no output schema, the description is too thin — it omits failure semantics, what constitutes a successful click result, and how target resolution errors surface. The absence of required parameters makes the omission of "what happens when target is null" a real gap.

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 44%, so meaningful compensation is needed. The description clarifies the semantics of expect (result verification) and the followNewTab default behavior, but leaves target vs selector precedence, button, session, and both timeout parameters entirely to 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?

States a specific verb and resource ("Click a unique actionable target") and reveals a non-obvious precondition: the target must resolve to a single element. It does not name how it differs from wb_dblclick, wb_hover, or wb_check, so the agent must infer the boundary from the verb alone.

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?

"Auto uses CDP in visible tabs, DOM in hidden tabs" gives context for which mode fires, but there is no explicit when-to-use-this-vs-siblings guidance and no exclusion of the near-identical click alternatives. The "auto-follow requires opener evidence" line is a constraint, not routing 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 clearly states the destructive scope ('Close ALL tabs') and adds a safety guard ('Only when the user asks to clear agent tabs'). It could be more explicit about irreversibility or side effects, but the main behavior is transparent.

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

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

The description is two short sentences, each earning its place. The first sentence states the action, and the second provides the usage context. 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 tool with one optional parameter and no output schema, the description provides enough context. It clarifies the action, scope, and when to use it. The session parameter is documented in the schema. It does not explain what 'session/group' means, but that is a minor gap.

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 covers 100% of the parameters, with the session parameter already described in the input schema. The description does not add any additional parameter semantics, so the baseline of 3 is appropriate since the schema does the heavy lifting.

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 and resource: 'Close ALL tabs in the session/group.' The qualifier 'Only when the user asks to clear agent tabs' further narrows the purpose and clearly distinguishes it from sibling tools like wb_close_tab, which presumably closes a single 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 explicitly says 'Only when the user asks to clear agent tabs,' which gives a clear condition for when to use this tool. It does not explicitly name the alternative for closing a single tab, but the contrast with wb_close_tab is implied. This is stronger than simply implying usage but lacks a direct mention of 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 must carry the full burden of behavioral disclosure. While 'Close the current tab' indicates a destructive action, it does not mention irreversibility, potential loss of unsaved work, behavior when closing the last tab, or which tab becomes active afterward. This is insufficient for a mutation operation.

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, focused sentence with no unnecessary words. It is front-loaded with the core action and easily parsed by an agent.

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 this is a destructive action with no annotations and no output schema, the description should explain consequences and side effects to be contextually complete. It only states the action, omitting important details like tab closure behavior, session implications, or error conditions. This is a clear gap for a tool that removes a resource.

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 fully documents the single 'session' parameter with a clear description ('Per-call session override (does not change the process default)'), so schema coverage is 100%. The description adds no extra meaning beyond this, but none is needed because the schema already covers the parameter adequately.

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 specific action ('Close the current tab') and the resource ('in the session'), which precisely differentiates it from sibling tools like wb_close_session (closes session) and wb_go_back (navigation). This is a specific verb+resource pairing that leaves no 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?

The description offers no guidance on when to use this tool versus alternatives. It simply states the action without providing context, prerequisites, or exclusions. An agent is left to infer usage from the name alone, with no explicit comparison to siblings like wb_close_session or wb_list_tabs.

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 burden of behavioral disclosure. It mentions 'install interceptor' for start, but does not explain side effects, persistence, or what 'list' returns. The behavior is partially transparent but missing notable 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 a single concise line with all commands, front-loaded with purpose and 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?

Given the tool's simplicity (2 params, 1 enum), the description covers all subcommands and core purpose. Lacks explicit output format details, but not critical for this narrow 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 100%, with clear enum for cmd and session override meaning. The description adds only minor context ('install interceptor') and does not need to compensate for schema gaps.

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 captures page console/errors and lists specific subcommands (start/list/clear/stop), clearly distinguishing it from sibling navigation and interaction tools. The verb 'capture' and resource 'page console/errors' are explicit.

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?

Schema adds 'start before actions you want to observe', giving timing guidance. No explicit alternatives or exclusions are mentioned, but the overall context is sufficient for an agent to infer when to use it.

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

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

With no annotations, the description carries the full burden, and it does disclose one valuable mechanism: auto mode uses CDP on visible tabs and synthetic DOM input on hidden tabs, with the mode reported back. It omits other behavior an agent needs — whether it waits for actionability, how it fails on ambiguous matches, and whether retries occur (that detail lives only in the schema).

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

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

Two tight sentences, zero filler, with the action statement front-loaded ahead of the mode-mechanics footnote. Nothing could be cut without losing information.

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 nested 6-parameter interaction tool with no annotations and no output schema, the definition covers the mode mechanism but leaves gaps: element actionability waiting, failure modes on non-unique targets, and the semantics of the `expect` block. Adequate to invoke, not sufficient to 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 coverage is 50%, and the nested `target` and `expect` objects have almost no per-field documentation, so the description has room to add value. It only weakly compensates, implying target uniqueness and explaining the inputMode auto/visible/hidden split. Target resolution order (css/ref/name/role) and the `expect` post-conditions remain undocumented in both places.

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?

States a specific verb ('double-click') and resource ('unique actionable element'), which cleanly separates it from the sibling wb_click. The 'unique' qualifier signals a targeting precondition. It stops short of explicitly naming wb_click as the single-click 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 verb itself implies when to reach for it (a double-click interaction), and 'unique actionable element' hints that non-unique targets are out of scope. However, there is no explicit when-to-use/when-not guidance, no mention of alternatives like wb_click, and no note on whether the agent should wait or snapshot first.

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 usefully discloses that it uses CDP, requires both targets visible simultaneously, and does not synthesize HTML5 DataTransfer events. It omits failure behavior, return values, and permission or timeout handling, leaving meaningful gaps for a mutation-like interaction tool.

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

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

Two tight sentences with zero filler, and the critical constraint about visibility and DataTransfer is front-loaded immediately after the purpose statement.

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 six parameters, nested selector objects, no annotations, and no output schema, yet the description covers only the core gesture concept and one limitation. It does not explain the complex source/destination selector structure, expect assertions, steps, session override, or timeout behavior, so an agent cannot confidently invoke it from this 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 only 17%, so the description must compensate for the undocumented nested source/destination selector objects, steps, expect, session, and timeoutMs. It merely alludes to 'two unique elements' without explaining any parameter formats or constraints, leaving most inputs unexplained.

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?

States a specific verb and resource: pointer drag between two elements via CDP. It clearly distinguishes itself from sibling interaction tools like wb_click, wb_hover, and wb_dblclick by specifying a drag operation and naming the underlying CDP mechanism.

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?

Implies usage context by stating both targets must be visible together and that HTML5 DataTransfer is not synthesized, which guides the agent away from HTML5 drag-and-drop scenarios. However, it does not explicitly name alternatives or say when to use this versus other interaction 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, the description carries the full burden. It reveals preferred return style and state management through IIFE, but does not disclose execution context, side effects on the page, error handling, or permissions required. This is a significant gap for a code execution tool.

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, front-loading the core purpose in the first sentence. The two additional tips are specific and actionable, with no fluff or wasted words. It is appropriately sized for the information it conveys.

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 powerful code execution tool with no output schema and sparse annotations. The description covers basic usage tips but omits crucial context such as return value format, error behavior, execution environment, and whether results are captured. Given the tool's power, the description is incomplete for an agent to use it 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 coverage is only 50% (session is described, code is not). The description adds no direct explanation of the 'code' parameter beyond 'run JavaScript,' and the session parameter is already explained in the schema. The guidance about returns and IIFE does not clarify parameter meanings or syntax.

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 'Run JavaScript in the page,' using a specific verb and resource. This distinguishes it from sibling browser automation tools like navigate, click, and fill, which perform different actions. The purpose is unambiguous.

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

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

The description provides no guidance on when to use this tool over alternatives, nor does it mention exclusions or prerequisites. It offers coding tips (compact JSON.stringify, IIFE) but no context on selecting this tool versus another. Sibling tools are not referenced for differentiation.

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 'clear-and-fill' is the one genuinely useful disclosure: pre-existing content is destroyed. Beyond that it is silent on whether input/change events are dispatched, what happens on non-fillable elements, error/failure behavior, and the timeout semantics. Substantive but far from complete.

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 padding, with the verb and eligible element types front-loaded. It stops short of being too terse to be useful, though the second sentence is closer to a schema echo than new information.

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 6-parameter tool with a nested target object containing seven sub-properties, no annotations and no output schema, the description covers almost none of the surface an agent must reason about: target-object precedence, session overriding, timeout bounds, and failure modes are all undocumented.

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 67%, so baseline is 3. The description reinforces the selector format ('@e or CSS'), but the schema's own selector description already says 'use selector OR target', so the added value is marginal, and the 7-property nested 'target' object (ref, role, name, exact, within, snapshotId) gets no explanation from the description.

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?

States a specific verb ('Clear-and-fill') and a specific resource scope (input/textarea/contenteditable), which is more concrete than the bare name wb_fill. It does not name the nearest sibling (wb_type) to draw the boundary, so it falls short of 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 instead of wb_type, wb_select, or wb_press_key, and no stated prerequisites such as the element needing to be focused or visible. The only directive-like text ('selector = @e or CSS') is a parameter format hint, not 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?

With no annotations provided, the description must carry the full burden of disclosing behavioral traits. It states that the tool 'Search[es]' and returns '@e refs when present', but it does not disclose whether it is read-only, what happens when there are no matches, whether it depends on a session, or any side effects. Since annotations are absent, this is insufficient 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 two short sentences with no redundant information. Each clause adds value: the first states the action and scope, and the second clarifies the output. The 'like Claude find' analogy is optional but not harmful. It is correctly sized for a simple search tool.

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 tool's relative simplicity and 100% schema coverage, the description is mostly adequate. However, the absence of an output schema and minimal behavioral disclosure leaves some ambiguity around return format and usage context (e.g., relationship between query and role, when to prefer this over wb_snapshot). The description covers the core purpose but lacks richer contextual 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?

The input schema provides descriptions for all four parameters (role, limit, query, session), giving 100% schema description coverage. The description adds the notion of searching by 'text/role' and returning '@e refs', but it does not meaningfully expand on the parameter semantics already captured in the schema, so the baseline of 3 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 clearly states a specific verb ('Search') and resource ('accessibility tree') with the method ('by text/role'), and distinguishes itself by noting it returns '@e refs', which is not mentioned for sibling tools like wb_snapshot or wb_find_tab. The analogy to 'Claude find' reinforces the intended 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 for searching an accessibility tree, but it does not provide explicit guidance on when to use this tool versus siblings like wb_find_tab or wb_snapshot, nor does it mention exclusions or prerequisites (e.g., whether a session must be active). The 'like Claude find' analogy hints at context but does not give concrete usage 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?

With no annotations, the description must carry the full behavioral burden. It usefully discloses that the tool 'Never navigates on failure' and that duplicate URLs require upstream ID support, but it omits whether selection activates/focuses the tab, what happens when the tab is missing, and how the session override behaves.

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?

Three short sentences, front-loaded with the core action, followed by failure behavior and the duplicate-URL constraint. No filler and no 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?

For a four-parameter selection tool with no annotations and no output schema, the description covers the selection mechanism and failure behavior but is silent on state effects (does it activate the tab?), error semantics, and the role of the session parameter. It is adequate but leaves meaningful 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?

The description adds real meaning beyond the schema by explaining that tabId is 'resolved to unique URL' and that URL matching must be exact and unique. Schema coverage is 75% (tabId lacks a description), so this added context is valuable, though active and session are left entirely to 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 states a specific verb and resource ('Select a session tab') and explains the two addressing modes (exact URL or tabId resolved to unique URL). It is distinguishable from wb_list_tabs and wb_close_tab by implication, though it does not explicitly name 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 duplicate-URL caveat ('Duplicate URLs require upstream ID support') gives a concrete condition for when URL-based selection fails, but the description never states when to use this tool versus wb_list_tabs or wb_navigate. Usage is implied rather than prescribed.

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 transparency burden. It discloses a key behavior ('visible page text') and references a familiar tool for behavioral grounding, but does not mention potential side effects, return format, or limitations (e.g., dynamic content, maxChars). This is minimal but not 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 exceptionally concise: two short sentences. Each sentence adds value—the first defines the action, the second provides a comparative usage hint. 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 with no required parameters and no output schema, so the description is mostly sufficient. However, it does not explicitly state what the return value looks like (e.g., plain text string) or any edge-case behaviors, leaving some ambiguity for an agent. 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?

Schema description coverage is 100%, with both parameters ('session' and 'maxChars') already documented in the schema. The description adds no extra parameter semantics, so the baseline of 3 applies.

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 ('Extract') and resource ('visible page text'), making the tool's function immediately obvious. It explicitly contrasts with 'full snapshot' and references 'Claude get_page_text', which distinguishes it from sibling tools like wb_snapshot.

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 usage context: it is better than a full snapshot for articles, implying use when text content is needed rather than page structure. While it does not explicitly state when NOT to use it or list alternative tools beyond snapshot, the comparison gives a strong hint of appropriate scenarios.

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 simply says 'Browser history back' without explaining side effects, limitations (e.g., behavior when history is empty), session handling, or whether this is a read-only operation.

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

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

The description is a single sentence that is front-loaded with the core function 'Browser history back'. It is concise and contains no unnecessary words, earning a high score for conciseness.

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 and the description captures the basic function, but it lacks context about edge cases, return values, or how the 'session' parameter influences behavior. Given there is no output schema and no annotations, the description is minimally adequate but leaves 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?

The input schema covers 100% of the parameter descriptions, including the optional 'session' parameter. The description adds no additional meaning about parameters, so the baseline score of 3 applies.

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 'Browser history back', which is a specific verb and resource. It distinguishes itself from sibling tools like wb_go_forward and wb_navigate by specifying the direction of history navigation.

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 no explicit guidance on when to use this tool versus alternatives such as wb_go_forward or wb_navigate. It only mentions 'Claude-in-Chrome style navigation helper', which is vague and does not clarify selection criteria.

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 of behavioral disclosure. It merely restates the tool name without adding any context such as effects on the page, session, or failure conditions (e.g., no forward history available).

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 short fragment, but it is under-specified rather than effectively concise. It does not provide enough content to justify its existence beyond the tool name, and the lack of a complete sentence reduces clarity.

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 navigation tool with no output schema and minimal annotations, the description is incomplete. It does not mention any prerequisites, side effects, or error conditions, leaving the agent without enough context to anticipate behavior in different situations.

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 describes the only parameter 'session' with 100% coverage, including its behavior as a per-call override. The description adds no parameter details, but since the schema fully documents it, the baseline of 3 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 phrase 'Browser history forward' clearly indicates the tool advances through the browser's navigation history. It implicitly distinguishes itself from the sibling 'wb_go_back' by specifying the forward direction, though it lacks a full verb phrase like 'Navigate forward'.

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. It does not mention that it should be used after a backward navigation or how it relates to wb_go_back, leaving the agent to infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no actionability/visibility waits, no statement about whether the pointer position persists, no failure or timeout behavior. The only behavioral signal is the passing note that it is useful for menus and tooltips, which hints at a reveal effect but does not explain any of the mechanics.

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, front-loaded with the action and the accepted argument forms, with zero filler. There is nothing to trim.

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 six parameters including two nested objects, no annotations and no output schema, the description leaves the agent guessing about waiting semantics, return value, and post-condition state. It should at minimum say whether the hover waits for the element to be visible/stable and what the tool reports on success or failure.

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%, and the nested `target` and `expect` objects are entirely undocumented. The description's '(@e or CSS)' line largely duplicates the schema's existing selector note ('Legacy CSS or @e reference; use selector OR target') and adds nothing about `expect`, `within`, `timeoutMs`, or how `session` overrides work.

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?

States a specific verb ('Hover/mouseover') and resource ('an element'), and names the accepted selector syntaxes ('@e or CSS'). It is clearly distinguishable from the sibling action tools (wb_click, wb_dblclick, wb_drag) by the verb alone, though it never names them explicitly.

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?

'Useful for menus and tooltips' implies the scenario where hover is the right choice rather than click, which is a real hint. But there is no explicit when-not guidance, no mention of what to do if the element isn't hoverable, and no pointer to alternatives such as wb_click for elements that need activation.

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 responsibility for behavioral disclosure. It only states the action ('List tabs') without any details about return format, whether it's a read-only operation, error conditions, or session handling. This lack of behavioral information makes the tool's behavior opaque.

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 is front-loaded with the primary action ('List tabs'). It contains no filler, redundant details, or unnecessary categorization. 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?

The tool is simple, but without an output schema, the description should clarify what the list contains (e.g., tab IDs, titles, URLs). It also doesn't mention any session-related behavior beyond the scope. The description is sufficient for a minimal understanding but lacks detail about the return value and session edge 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 coverage is 100% since the only parameter 'session' has a clear description ('Per-call session override'). The tool description adds no parameter-specific information, but the schema already provides sufficient meaning. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool's function: 'List tabs belonging to the current session (tab group).' The verb 'List' and resource 'tabs' are specific, and the scope ('current session') is explicit. This distinguishes it from sibling tools like wb_find_tab or wb_close_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 use when you need to enumerate tabs, but it does not explicitly state when to use this tool versus alternatives like wb_find_tab, nor does it mention any preconditions or exclusions. Usage context is only implied, not spelled out.

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 adds useful behavioral context: the browser is 'real', group_title is expected on first call, and newTab controls tab coexistence. However, it does not disclose whether navigation waits for page load, what happens to the current tab by default, or any other side effects, leaving some 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?

The description is two sentences, front-loaded with the core purpose, and every clause adds value. There is no redundancy or filler.

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 without an output schema or annotations, but the description plus schema fully document all parameters and provide key usage guidance. It is adequate for a navigation tool, though it could mention whether navigation is synchronous or waits for load for greater completeness.

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 baseline is 3. The description adds operational meaning beyond the schema by clarifying when to use group_title (first call of a task) and newTab (when pages should coexist), which enhances schema descriptions like 'Human-readable tab group label' and 'Open in a new tab (default false)'.

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 ('Open or navigate to') and identifies the resource ('a URL in the real browser'). It clearly distinguishes the tool from siblings like wb_go_back, wb_go_forward, and wb_reload, which handle navigation history rather than direct URL entry.

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 explicit usage context: 'First call of a task should pass group_title' and 'Use newTab:true when pages should coexist.' This tells the agent when to use the tool and how to apply options, though it does not explicitly discuss alternatives or exclusions relative to sibling navigation 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?

No annotations are provided, so the description carries full behavioral disclosure responsibility. It only enumerates the cmd values (start|stop|list|detail) but does not explain stateful behavior, such as whether start clears previous captures, how list returns data, or what detail requires. This is insufficient for a tool with no annotation safety hints.

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 one sentence plus the cmd enumeration. Every word is informative, and the structure is front-loaded with the tool's purpose before listing subcommands. This is appropriate for the tool's simplicity.

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 only 25% parameter coverage, the description should provide more context about return values, state management, and parameters. It does not explain what list or detail outputs look like, how filter interacts with commands, or what session overrides imply. This is incomplete for a stateful capture 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 low (25% only for session), and the description does not compensate. It repeats the cmd enum values already present in the schema but adds no explanation for filter or requestId parameters. The description adds no new semantic 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 'Capture/list network requests' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling tools, none of which deal with network traffic, and lists subcommands (start|stop|list|detail) that further clarify the intended actions.

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 no explicit guidance on when to use this tool versus alternatives or when to prefer one subcommand over another. The purpose statement implies it is for network request capture, but there is no context about typical scenarios or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens if no element is focused, whether the key press triggers navigation or events, or any side effects. The comparison to Claude press_key is vague and doesn't reveal concrete behavior.

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 concise and front-loaded with the action ('Press a key or combo'). The reference to 'Like Claude press_key' is short but may be unnecessary for an agent unfamiliar with Claude. Overall, it is efficient with minimal 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?

Given no annotations, no output schema, and a simple 2-parameter schema, the description is too sparse. It does not explain expected return values, errors (e.g., no focused element), or how the 'session' parameter affects behavior. The tool is simple, but the description lacks context needed for reliable 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 100%, and the schema already documents both 'key' and 'session' with examples. The description adds the phrase 'on the focused element' but does not provide additional semantics beyond schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 presses a key or combo on the focused element, with specific examples (Enter, Escape, Tab, Control+A). This distinguishes it from sibling tools like wb_click or wb_fill, but the reference 'Like Claude press_key' is slightly ambiguous and doesn't explicitly differentiate from all 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?

No explicit guidance on when to use this tool versus alternatives. The phrase 'on the focused element' implies it is for keyboard interactions, but there is no mention of prerequisites, exclusions, or when to prefer wb_click or wb_fill. The 'Like Claude press_key' comparison is not a practical usage guideline.

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 does add value by noting 'hard:true bypasses cache when CDP allows,' which reveals a caching nuance and a potential limitation. However, it does not mention side effects such as losing unsaved page state or whether the tool waits for the reload to complete.

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 concise, with exactly two short sentences that immediately state the action and then explain the key option. It avoids redundancy with the schema and earns its place.

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 reload tool with two optional parameters and no output schema, the description is mostly sufficient. It covers the core purpose and the notable hard-reload behavior. Minor gaps include not describing return behavior or what happens if the current page is in an unloadable state, but these are not critical for selecting this 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 schema already documents both parameters (hard, session) with 100% coverage, so the baseline is 3. The description adds meaningful context by clarifying that 'hard:true' bypasses cache only 'when CDP allows,' which qualifies the parameter's effect beyond the schema's generic description.

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: 'Reload the current page.' This distinguishes it from sibling navigation tools like wb_go_back, wb_go_forward, and wb_navigate, which involve changing the page rather than refreshing it.

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 page reload is needed, but it does not explicitly state when to prefer this over alternatives or provide exclusion criteria. The phrase 'current page' gives context, but no direct 'use this instead of X' guidance is offered.

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 real work: it discloses bounded retries, that the original file is preserved, and that oversized images are downscaled into JPEG previews with dimensions reported. What is missing is prerequisite context (an active session/current tab is required) and where the artifact lands when no path is given.

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 tight sentences, front-loaded with the core action, then the output guarantees. Every clause (retries, preservation, resizing, dimensions) carries information an agent needs; nothing is padding.

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 6-parameter, zero-required, no-output-schema, no-annotation tool, the description covers output behavior but omits the prerequisite that a live session/current tab must exist and leaves `path` (and the default save location) unexplained. Adequate but with clear gaps for a tool this configurable.

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 83%, so the schema already explains format, quality, session, selector and timeoutMs; the baseline is 3. The description adds only the 'oversized images get resized' nuance and says nothing about the completely undocumented `path` parameter, so it does not compensate for the remaining 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?

States a specific verb+resource ('Screenshot current tab') and clarifies the optional selector variant, which distinguishes it from sibling read tools like wb_snapshot and wb_get_text. It does not explicitly name the alternative for text/DOM extraction, so it stops 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?

Usage is only implied — an agent infers you call this to capture a visual of the page. There is no guidance on when to prefer wb_snapshot or wb_get_text, no statement about needing an active session/tab, and no advice on choosing selector cropping vs. a full-tab capture.

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 of behavioral disclosure. It doesn't state whether scrolling waits for completion, what it returns, whether it is read-only/non-destructive, or how container scoping behaves – only the bare scroll modes are described.

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, front-loaded with the action and immediately followed by the three modes. Every phrase earns its place with no 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?

For a 7-parameter, zero-required, no-annotation, no-output-schema tool, the description is thin: it doesn't explain the container/session semantics, default scroll amount behavior, or what the result looks like. The high schema coverage partially compensates, but gaps remain around behaviors the schema can't express.

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 86%, so the schema already documents x, y, amount, session, selector, container and direction well. The description mostly restates those modes and doesn't add meaning beyond what the schema provides, so baseline 3 applies. It omits mention of container and session entirely.

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?

States a specific verb (scroll) and resource (page or element) with the three invocation modes (direction, x/y deltas, selector/@e). It clearly conveys what the tool does; sibling differentiation is implicit since no other tool in the list scrolls.

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 three modes (direction, x/y deltas, selector/@e) imply which parameters to combine for a given intent, but there's no explicit when-to-use vs alternatives, no exclusions, and no guidance on which mode to prefer for a given goal.

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. 'Verify selection' usefully signals a post-action read-back, but it omits critical behavior for a select tool: whether change/input events are dispatched, what happens when a value matches no option, multi-select semantics, and whether it works in hidden tabs (the inputMode enum hints at this but the description is silent).

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 with zero filler, and the primary action is front-loaded before the exclusion. Nothing to trim.

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?

Six parameters including a nested target object with eight sub-fields, no output schema, and no annotations leave a large disclosure gap. For a mutation tool of this complexity the description should cover matching semantics, failure behavior, and multi-select handling; the current two sentences do not.

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 50%, and the description adds almost nothing: it does not explain whether 'values' are matched against option labels or value attributes, how multiple values behave, or how target/selector/inputMode interact. The single mention of 'option values' is the only hint and leaves the core matching semantics ambiguous.

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 a specific verb+resource pair ('Set native select option values') plus a verification step, and explicitly scopes out custom dropdown widgets, which lets an agent distinguish this from wb_click/wb_fill. It stops short of naming the sibling to use for custom dropdowns, so it is clear but not fully differentiated.

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?

'Does not support custom dropdown widgets' provides an explicit when-not, which is real routing guidance. However, there is no explicit when-to statement and no named alternative for the custom-widget case, so the agent must infer that wb_click is the fallback.

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 is the sole behavioral source. It implies a non-destructive read operation via 'snapshot' and 'prefer before click/fill', but it does not explicitly state side effects, permissions, or response 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 two sentences with no wasted words. It front-loads the core definition and immediately follows with a practical usage directive.

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 of this simplicity, the description covers purpose and usage context well. It does not explicitly state that the operation is read-only or describe return formatting, but the schema and the phrase 'accessibility tree' provide enough context.

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 only parameter, 'session', is fully documented in the input schema with 100% coverage. The description adds no additional nuance about this parameter, but the schema already provides sufficient 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 identifies the tool's output as an accessibility tree with element references, and it distinguishes itself from sibling navigation/action tools. It lacks an explicit verb like 'get' or 'retrieve', but 'snapshot' combined with 'accessibility tree' makes the purpose apparent.

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 instruction 'Prefer before click/fill' provides a clear context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the stated preference is strong situational 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 present, so the description carries the full burden. The verb 'Check' and the phrase 'call first if unsure' imply a safe, read-only status operation. It does not elaborate on return format or error behavior, but for a simple status check this is sufficient.

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: the first states what the tool does, the second gives usage guidance. Every word earns its place, and 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 zero-parameter status check with no output schema and no annotations, the description fully covers purpose and usage. It specifies what is checked (daemon + extension) and when to call it (first if unsure). No relevant gaps exist.

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 parameter semantics are trivially satisfied. The description doesn't need to explain params, and the empty input schema confirms this. Baseline 4 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 clearly states 'Check WebBridge daemon + browser extension connection,' with a specific verb and resource. It distinguishes itself from sibling tools by being the only readiness check tool among action-oriented wb_* 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?

The guidance 'Call first if unsure whether the bridge is ready' is explicit and direct, telling exactly when to invoke this tool. This is strong usage guidance, equivalent to naming alternatives or 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?

With no annotations, the description carries the load and does disclose two real traits: it appends at the caret rather than overwriting, and it performs no verification of success. It omits whether focus is required, what happens on hidden tabs, and whether CDP failure surfaces as an error or silence.

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 clauses, the core behavior front-loaded, and the verification caveat placed as a compact imperative. Nothing redundant.

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 6-parameter tool with a nested target object, no annotations, and no output schema, the description is too thin. The selector/target duality, session scoping, and the ambiguous inputMode semantics — the places an agent will actually get it wrong — are all unaddressed.

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 50%, so the description needed to compensate and does not. 'The target's caret' vaguely gestures at the target object, but the legacy selector-vs-target choice, session override, timeoutMs, and inputMode's applicability to typing are all unexplained (the inputMode description in the schema actually discusses click/check, muddying whether 'dom' is valid here).

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?

States a specific verb and effect: insert text at the target's caret, explicitly not replacing existing text, delivered via CDP. That non-replacing qualifier is what separates it from wb_fill, though the sibling is never named outright.

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 statement of when to pick this over wb_fill or wb_press_key, and no prerequisites (does the element need focus first? does it work in hidden tabs?). The trailing 'Verify the result separately' hints at a follow-up call but gives no condition or named alternative.

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 path format restrictions and the requirement that the input element already be present. However, it doesn't mention what happens if the selector doesn't match, whether change/input events are fired, or error behavior—leaving some transparency gaps.

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

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

Two sentences, front-loaded with the verb and resource, and every sentence adds essential information. No fluff 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?

Given the tool's simplicity and no output schema, the description covers key constraints (path format and page condition) and the input schema defines required parameters. It's reasonably complete for a straightforward file upload tool, though it could explain error handling or interaction with dynamic pages.

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 covers 67% with descriptions for files and session, but selector lacks description. The description adds meaning beyond the schema by clarifying that files must be absolute local paths, not URLs, and that the page must already have the input element (which informs how selector should be used). This adds concrete value.

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 ('Set files on a file input element') and specifies the resource type. It distinguishes itself from sibling tools like wb_fill and wb_click by focusing exclusively on file inputs, and immediately adds critical constraints (absolute local paths, existing input element).

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?

Provides explicit conditions for use: files must be absolute local paths (not http/data URLs) and the page must already show an <input type=file>. This gives clear context and prerequisites. It doesn't explicitly name alternatives, but the constraints and sibling list imply that this is the file-specific 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. It does signal that the call blocks and is bounded by a timeout, which is the key behavioral trait, but it does not say what happens on timeout (throw vs. return false), whether multiple conditions AND together (only the schema says this), or that it polls at an interval.

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?

A single tight sentence with the core conditions front-loaded and no filler. It is arguably too terse for a blocking tool, but nothing in it 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?

For a 7-parameter, zero-annotation, no-output-schema tool, the description omits the timeout failure mode and the return value, both of which an agent needs to branch on. The schema fills in parameter-level detail, but overall behavior around failure and results is left unstated.

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 100%, so all seven parameters, including the state enum and default values, are already documented. The description adds only the high-level mapping of conditions; 'document is ready' loosely corresponds to the url parameter, which could mildly confuse an agent expecting a readiness flag.

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?

Specific verb 'wait' with three named conditions (text appears, CSS selector matches, document ready), which clearly distinguishes it from immediate-read siblings like wb_get_text and wb_snapshot. It does not explicitly name any sibling as an alternative, but the purpose is unambiguous.

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

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

Usage is implied: call this to block until a condition holds, presumably after wb_navigate or before reading/clicking. However, the description never states when to prefer this over polling with wb_find/wb_get_text, nor any preconditions such as an active session requirement.

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