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 a non-obvious behavior: automatic switching to newly opened tabs after click. It also highlights the followNewTab default. Missing details like wait behavior or error handling, but the main side effect is covered.

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, well-structured sentence that front-loads the action, includes selector guidance, and explains the default tab behavior. Every word 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 simple click tool with fully described parameters and no output schema, the description covers the primary behavior and the main side effect (tab switching). It doesn't explain return values, but that is unlikely to be critical for a click action.

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 baseline is 3. The description adds value by indicating that @e refs are preferred over CSS selectors, and reiterates the default tab-following behavior which complements the schema's parameter 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 action ('Click an element') with specific resource and selector preference. It distinguishes itself from siblings like wb_fill or wb_press_key by focusing on element clicking, and provides useful context about tab 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 gives clear context on how to use the tool ('@e ref preferred, or CSS') and the default tab-following behavior. It implicitly indicates when to use (for clicking elements) without explicit alternatives, but the context is sufficient for 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 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. 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?

The description discloses the core behavior of clearing existing content before filling, which is important for a mutation tool. It also explains the selector format ('@e or CSS'), which is useful. However, it doesn't mention potential side effects like triggering input events or requiring element visibility, and there are no annotations to fall back on.

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. Two short sentences communicate the main action and the crucial selector syntax without any unnecessary words. Every part 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 fill tool, the description provides essential information but lacks details about return values, error conditions, or timing. It also doesn't mention the 'session' parameter. With no output schema and no annotations, the description is adequate for basic use but not fully complete for an agent making decisions.

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 'value' with a description and 'selector' with minLength, but not the 'session' parameter. The description adds meaning to 'selector' by specifying '@e' or CSS, which is beyond the schema. However, it doesn't explain 'session', and with 67% schema coverage, the description only partially compensates for the 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 clearly states the action 'Clear-and-fill' and the target resources 'input/textarea/contenteditable'. It distinguishes from sibling tools like wb_click or wb_get_text by focusing on filling form elements. However, it doesn't explicitly differentiate itself from similar tools like wb_upload or wb_press_key, so it's not a full 5.

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

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

The description implies usage for filling input fields but does not provide explicit when-to-use guidance or alternatives. There's no mention of when not to use this tool (e.g., for file uploads) or which sibling tool might be more appropriate for other 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 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 carries the full burden of disclosure. It adds useful behavioral details (fuzzy URL match with trailing slash/query tolerance, active:true borrowing the focused tab), which are valuable. However, it does not disclose what happens when no tab matches, whether errors are thrown, or the side effect of changing the current tab (a mutation), which are important for safe use.

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 only two sentences, yet it packs essential information: the primary action, the fuzzy matching tolerance, and the active:true behavior. Every sentence earns its place, and it is front-loaded with the core purpose. 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 has no output schema and relatively simple behavior, the description covers the main functionality. However, it omits return value details and error cases (e.g., what if no tab matches? does it throw? returns null?). It also doesn't clarify whether selecting a tab has any other side effects beyond changing the active tab. A bit more detail would make it more 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 100%, so baseline is 3. The description adds meaningful context beyond the schema: it explains what 'fuzzy' means (trailing slash/query tolerant) and clarifies the active:true behavior ('borrows the focused session tab when possible'). This enhances parameter understanding beyond the schema's 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's action ('Select a tab as current') and resource (tab), and the fuzzy URL matching distinguishes it from listing tools like wb_list_tabs. However, 'Select a tab as current' is slightly terse and could be more explicit that it makes the tab the active/current one, rather than merely finding 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 for switching the active tab by URL or active flag, and it provides context about fuzzy matching and active:true behavior. However, it does not explicitly state when to use this tool versus alternatives (e.g., wb_list_tabs for listing, wb_navigate for navigation), 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?

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 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 provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the reliability-motivated default format, auto-retry with smaller jpeg on timeout, path return, image embedding under a size cap, and error format including problem and hint. This is strong transparency for a screenshot tool, though it does not cover potential side effects or permission requirements.

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, each with a distinct purpose: purpose, format default/retries, return behavior, and error format. No filler or repetition. The most important information (what it does) is front-loaded in the first sentence.

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 5 optional parameters and no output schema, the description covers the key runtime behaviors: return value (path), embedding, retries, and error structure. However, it lacks any description of what the 'path' parameter does as an input, and does not mention potential side effects or restrictions. Overall, it is reasonably complete for a screenshot utility.

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 80% (format, quality, session, selector have descriptions), so the baseline is 3. The description adds context about format reliability and retries, but it does not explain the 'path' parameter, which remains ambiguous (input destination vs. output path). The description fails to fully compensate for the 20% gap in 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 opens with a clear verb and resource: 'Screenshot current tab (or selector).' It immediately distinguishes the tool's purpose from siblings like wb_get_text or wb_navigate, and the mention of selector adds a specific capability. The behavior described (format, retries, embedding) reinforces a unique identity.

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 no guidance on when to use this tool instead of siblings such as wb_snapshot or wb_get_text. It does not mention exclusions or alternative tools, leaving the agent to infer usage solely from the purpose statement. The 'use for large pages' hint appears only in the schema's selector parameter, not in the main 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?

No annotations are provided, so the description is the sole source of behavioral disclosure. It explains that scrolling can target the document or an element and supports relative deltas, but it omits details such as whether x/y are relative, what happens when multiple modes are combined, and 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?

The description is a single compact sentence that front-loads the action and then lists all parameter modes without filler. Every phase maps directly to schema properties.

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 non-destructive, multi-mode scroll tool with no output schema, the description covers the main interaction modes and the schema fills in parameter details. However, it lacks explicit guidance on parameter exclusivity and behavior when no parameters are supplied, which keeps it just below a perfect score.

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 high (83%), but the description adds semantic grouping: direction vs x/y deltas vs selector/@e. This helps the agent understand which parameter mode to choose, beyond the raw schema properties.

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 uses the specific verb 'Scroll' with a clear target ('page or element') and enumerates three invocation modes (direction, x/y deltas, selector/@e). This clearly distinguishes it from sibling navigation, tab, and click 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 first sentence states the core use case and the 'or' chain clarifies mode selection. While it doesn't explicitly name alternative tools, no sibling offers scrolling functionality, so the usage context is clear without 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 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?

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?

No annotations are provided, so the description must carry the transparency burden. It discloses the timeout aspect but does not clarify what happens on timeout (e.g., error thrown, boolean returned, or null) nor whether the tool waits for all conditions simultaneously or any one of them. This leaves important behavioral details ambiguous.

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 directly conveys the tool's purpose and key conditions. There is no redundancy or filler, every word 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 wait tool with no output schema, the description covers the main behaviors (wait conditions and timeout). The only gap is the lack of detail on timeout behavior and the somewhat ambiguous 'document is ready' phrase, but overall it is sufficient 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?

Schema description coverage is 100%, meaning every parameter already has a description in the schema. The tool description adds no extra semantics beyond mentioning 'text', 'CSS selector', and 'timeout', which are already covered by the schema's parameter descriptions. Thus, the description does not add value 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's function with a specific verb ('wait') and lists three concrete conditions (text appears, CSS selector matches, document is ready) along with a timeout. This distinguishes it from siblings like wb_navigate or wb_click, which perform different 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 clear context on when to use the tool: to wait for text, selector, or document readiness. It does not explicitly mention alternatives or when not to use it, but the conditions are self-explanatory and typical for synchronization, making the usage almost self-evident.

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