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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the waiting behavior (timeout), the return fields (visibilityState, visible, reason), the fact that 'focused is not success', and that it does not change the URL. It also covers permission-denied and document-unavailable scenarios.

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 paragraph that front-loads the core purpose, then covers conditions, usage, and caveats. Every sentence adds value and there is no redundancy. It is concise while being comprehensive.

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?

Despite no output schema and no annotations, the description covers the essential behavior, return values, error reasoning, and usage constraints. It leaves no critical gap for an agent to call the tool correctly, given the tool's moderate complexity.

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 both parameters (tabId and sessionTabId) are already documented in the schema, including the default resolution order. The description does not add parameter-specific detail beyond the schema, so a 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 states a specific verb ('Focus') and resource ('an allowed tab and its window') and explicitly distinguishes from navigation ('without navigating'). It also mentions the context of failure (DOCUMENT_HIDDEN), making it clear what the tool does and how it differs from siblings like navigate.

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 when-to-use guidance ('Use this when click/type fail with DOCUMENT_HIDDEN') and when-not-to-use allowHidden ('Pass allowHidden=true only when visibilityState is hidden'), plus troubleshooting for specific reason codes. It clearly tells the agent when to choose this tool over alternatives.

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

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

No annotations are provided, so the description itself carries the transparency burden. It clearly frames the operation as a read-only status/check action: 'check whether', 'read nextAction', and 'read cdpEnabled and attachedTabs'. It does not go into failure details or permissions, but the behavioral intent is transparent and not misleading.

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

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

The description is three short sentences with no filler. The first sentence states the core purpose, and the next two sentences add useful read-field context. The content is front-loaded and every sentence contributes to the agent's decision to invoke the 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?

This is a low-complexity, no-parameter status tool with a straightforward goal. The description covers the purpose and names the key response fields to inspect (nextAction, cdpEnabled, attachedTabs), which respects the lack of an output schema. It does not mention failure modes or field types, but those are not critical at this complexity level.

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

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

The input schema has zero parameters and the schema description coverage is 100%, so there are no hidden parameters to document. Baseline for zero-parameter tools is 4, and the description adds no malformed parameter claims. It instead hints at response fields rather than input field, which is appropriate 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?

The description states a concrete action: checking adapter-to-broker connectivity and whether the Chrome extension answers a ping. It names the specific resource (browser bridge status) clearly. It does not explicitly differentiate itself from sibling tools like page_status, but the broker/extension focus makes the purpose distinct enough.

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 some usage context: use it for broker/extension readiness and read nextAction for onboarding coaching. It also gives a conditional instruction to read cdpEnabled and attachedTabs when the extension responds. However, it does not explicitly say when to prefer this tool over siblings such as page_status or list_tabs, nor does it give exclusion 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, the description carries full behavioral burden. It discloses multiple operational details: required popup toggle, claimed tab, allowed origin, debugger permission in manifest, Chrome debugging banner, and that repeating attach refreshes TTL without socket teardown. This goes well beyond the schema and gives the agent a realistic expectation of side effects.

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

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

The description is four sentences, each adding value: the action, prerequisites, permission/banner, and TTL refresh behavior. It is front-loaded with the core purpose and avoids redundancy. No 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?

Given the tool's complexity (requires multiple prerequisites, has permissions and side effects), the description covers all necessary context: what it does, when it's valid, required permissions, and behavior on repeat. It doesn't cover error cases or return values, but there's no output schema, and the description is sufficient for an agent to decide when and how to invoke it.

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 both parameters (ttlMs and sessionTabId) are already well-documented with meanings and defaults. The description adds the TTL refresh behavior on repeat attach, which is useful but is more of a behavioral note than parameter semantics. It doesn't add new meaning to the parameters themselves, so baseline 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 uses a specific verb ('attach') and resource ('trusted CDP input') to a claimed tab, clearly distinguishing it from siblings like cdp_detach (detach) and claim_tab (claim). It also states the effect: while attached, certain steps use trusted CDP input. This is unambiguous and non-tautological.

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

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

The description gives explicit prerequisites (popup enableCdp toggle, claimed tab, allowed origin) and notes the debugger permission and Chrome banner. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that an agent can infer this is the tool to attach CDP input, versus cdp_detach for detaching. It's more than implied but lacks explicit when-not guidance.

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

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

With no annotations, the description carries the full burden. It explains the transformation (input returns to content-script path) and a notable nuance about finalize_tabs and kept claims. It doesn't mention preconditions like whether the tab must be claimed, or failure states, but the core 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?

Two terse sentences. The first gets straight to the action; the second adds necessary sibling context without redundancy. No filler, and the key concept 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?

The tool has no annotations and no output schema, so the description must supply most of the context. It is thin on parameters, prerequisites, return values, failure behavior, and assumes prior knowledge of internal concepts like 'trusted CDP input', 'claimed tab', and 'finalize claims'.

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

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

Schema coverage is 0% and the description never mentions tabId or sessionTabId. 'Claimed tab' hints at tabId's role, but sessionTabId is entirely unexplained, and there is no guidance on which parameter is needed or how they interact.

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 clear verb ('Detach'), resource ('trusted CDP input'), and effect ('return click/type/keypress to the content-script path'). It also names sibling detaching tools, helping distinguish them, though it doesn't articulate the exact selection difference between them.

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

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

The description implies when this tool is relevant (when detaching trusted CDP input while preserving the content-script path) and notes that release_tab and finalize_tabs also detach. However, it gives no explicit conditions for choosing one over the other, nor any 'when not to use' guidance.

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

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

With no annotations, the description carries the full burden, and it delivers: 'in-memory' signals ephemerality, 'Rows are metadata only' sets expectations about data richness, and the explicit exclusions prevent the agent from assuming headers or bodies are present. It does not cover failure modes or whether an active watch is required, but the disclosed traits are genuinely useful beyond 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?

Three short sentences totaling roughly 27 words, with the primary action front-loaded and the exclusions following logically. Every sentence earns its place; there is no filler or repetition of the title.

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

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

For a simple one-parameter list tool, the core behavior and data boundaries are well covered. The main gap is that with no output schema, the description does not specify which metadata fields each row contains (URL, status, timing), leaving the agent to guess at the row structure.

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% — sessionTabId is fully documented as 'Claimed tab session id returned by claim_tab.' The description adds nothing about the parameter itself, but the schema is doing the heavy lifting, 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 names a specific verb ('Return'), resource ('in-memory network request index'), and scope ('for an attached tab'), which is further reinforced by the title 'List watched network requests'. The explicit exclusions ('Response headers, Set-Cookie, and request post data are never included') delineate it from cdp_response_body, so an agent can distinguish it from siblings without opening any schema.

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: use it to retrieve the metadata-level network request index for an attached tab. The 'never included' phrasing acts as a when-not boundary (do not use if you need headers, cookies, or post data), but it does not explicitly name an alternative tool like cdp_response_body or note the prerequisite of cdp_network_watch.

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 exist, so the description carries the transparency burden. It discloses that only metadata is indexed, that no response body is read/stored, and that restricted-category origins never enter the index. This covers the key safety- and privacy-relevant behaviors. It does not mention whether the watch persists across navigations or how to stop it, but the disclosed traits are substantial.

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?

Five sentences, each earning its place: purpose, exclusions, behavioral constraints, prerequisite, and optional parameters. The key purpose is front-loaded and clarifies scope immediately. Slightly longer than the terse 2-sentence examples but not padded.

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

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

This is a moderately complex tool with no output schema or annotations. The description explains the intended lifecycle, captures safety behavior, and names the prerequisite (cdp_attach). It doesn't describe its return value or how to stop/clear the index, but the core invocation rules and constraints are present and sufficient for correct use.

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%, and the description adds no new parameter-level semantics beyond what the schema already provides. The description repeats that optional patterns narrow URLs but does not add format details, defaults, or interaction rules; thus 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 names the specific verb ('Enable the Network domain') and the resource ('an attached tab') and states it keeps an in-memory index of metadata. It also explicitly says 'No response body is read or stored', which distinguishes it immediately from cdp_response_body and cdp_network_requests.

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 states 'Requires cdp_attach' and explains optional patterns narrow indexing, but does not explicitly say 'use cdp_network_requests to retrieve this index' or 'do not use when you need response bodies'. Since the sibling tools make the relationship inferable, this is clear context without full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers allowlist denials, restricted-origin refusal, binary-body refusal, size caps, token-mask limitations, header/non-body data never being exposed, and the append-only metadata log. This goes far beyond a simple mutation warning and gives the agent a realistic security model.

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 dense and front-loaded with the core purpose, then enumerates every consequential constraint. Every sentence adds a meaning, such as allowlist, binary limits, size cap, masking, and metadata logging. It is longer than minimal but justifies its length given the tool's security-critical behavior.

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 output schema and a non-trivial CDP response body tool, the description should explain what the agent will receive on success and failure. It details many error/denial behaviors but never tells the shape of a successful body (e.g., text content, JSON object, or raw bytes). There is enough behavioral context for safe invocation, but the missing return contract is 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?

The input schema already describes both parameters completely: requestId is from cdp_network_requests and sessionTabId is a Claimed tab session id returned by claim_tab. With 100% schema coverage, the description adds no additional parameter-specific detail, 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 opens with a specific action and resource: 'Read one response body by requestId from an attached tab.' This clearly differentiates it from siblings like cdp_network_requests and cdp_network_watch, and the title 'Read one response body' reinforces the exact scope.

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 when to use the tool by stating it operates on a requestId from an attached tab and under an explicit allowlist, but it does not directly compare to sibling tools or state when not to use it. There is no explicit routing such as 'use cdp_network_requests first' or 'prefer this over cdp_network_watch for single body reads.' Use is inferable but not explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds context about advisory default and exclusive lease behavior with TTL, which is valuable. However, it does not mention side effects, failure modes (e.g., what happens if the tab is already exclusively claimed), or the non-destructive nature of claiming. The description gives partial insight but leaves important operational details unspecified.

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

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

Two sentences, front-loaded with the primary purpose and immediately followed by the most important usage decision (advisory vs exclusive). No filler or redundancy. Every word contributes to comprehension.

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 claim tool with 4 params and no output schema, the description covers the critical decision point (exclusive vs advisory) and TTL semantics. It does not explain return values or error conditions, but given the simplicity and the presence of sibling tools like list_tabs and release_tab, this is largely sufficient. A minor gap is the lack of information about contention or failure when an exclusive claim is already held.

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 75% (tabId lacks a description). The description adds semantic meaning beyond the schema by explaining the advisory/exclusive distinction and linking exclusive=true with ttlMs for lease semantics. It also implies that tabId must refer to an 'allowed' tab, which is a constraint not stated in the schema. This meaningfully helps an agent select correct parameter values.

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 clear verb ('claim') and resource ('Chrome tab') with a specific scope ('for this browser-control session'). It distinguishes itself from siblings like release_tab and list_tabs by defining the claim action precisely. The wording leaves no ambiguity about what the tool does.

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

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

Provides explicit guidance on when to use exclusive mode versus advisory claims, mentioning 'fail-fast tab leases across parallel agents'. It does not explicitly name alternative tools or exclusions, but the context of advisory vs exclusive gives actionable decision-making. Slight gap: doesn't state when to prefer this over release_tab, but that is inferred from the verb.

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

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

With no annotations, the description carries the burden. It discloses important error behavior (fails with DOCUMENT_HIDDEN unless allowHidden=true) which is useful context. However, it does not mention other behavioral aspects such as potential navigation, scroll behavior, or return values. The disclosed error is beneficial but the overall behavioral coverage is minimal, so a 3 is appropriate.

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

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

Two concise sentences efficiently describe the core capability and a critical error condition. The key information is front-loaded, with no redundant text. 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?

The tool has a rich nested 'after' object with waitFor, snapshot, and pageStatus options, but the description does not mention that these abilities exist or guide when to use them. Nor does it describe the return value. While the schema covers parameter details, the description lacks guidance on optional post-action observations, leaving an agent to discover that from schema alone. This is a moderate 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 coverage is 83%, so the schema documents most parameters. The description adds little beyond what schema descriptions already provide (e.g., documentId's 'returned by list_frames' is duplicated). It clarifies that ref is from a snapshot and that documentId is exact, but these are already implied. A baseline 3 fits given the high schema coverage.

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

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

The description clearly states the tool's action ('Click an element'), the resource ('by snapshot ref'), and the scope ('current top document or an exact documentId from list_frames'). It distinguishes from click_at by specifying the input type, making the tool's purpose unambiguous even among siblings.

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

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

The description implies usage (when you have a snapshot ref) but does not explicitly contrast with alternatives like click_at (for coordinate clicks) or type (for keyboard input). It mentions the DOCUMENT_HIDDEN condition and allowHidden workaround, but no explicit 'when not to use' guidance or alternative tools are cited.

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 behavioral disclosure burden. It does disclose the DOCUMENT_HIDDEN failure mode and the allowHidden=true override, which is useful. However, it does not describe return values, navigation side effects, or any post-click behavior, so the transparency is adequate but incomplete.

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

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

Two sentences, front-loaded with the action and target, and no filler. Every clause earns its place: top document vs iframe, coordinate space, and hidden-document failure behavior.

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 tool with a nested 'after' object and no output schema, the description covers the core invocation details: coordinates, document targeting, and hidden-document handling. Optional wait/snapshot behavior is documented in the schema, so the description is mostly complete for correct tool selection and basic invocation, though return behavior is not addressed.

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 leaves x and y as bare numbers, but the description adds crucial meaning by distinguishing tabViewport coordinates from frameViewport coordinates and linking the latter to an exact iframe documentId. With 71% schema description coverage, this is meaningful compensation beyond the structured 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 ('Click'), a precise resource ('tabViewport coordinates' or 'frameViewport coordinates'), and the exact targeting context (top document vs iframe documentId). It clearly distinguishes click_at from the sibling click tool by emphasizing coordinate-based targeting rather than element/selector-based clicking.

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 for when to use it: click in the top document, or in an exact iframe by documentId. It also explains the hidden-document failure and allowHidden override. It does not explicitly name an alternative tool or say 'do not use when a selector is available,' but the coordinate-space wording makes the intended use clear.

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 available, the description carries the burden of behavioral disclosure. It reveals the hard ceiling on steps, optional nested scroll targeting, early-stop conditions, and stoppedReason in results. This goes beyond a tautology, though it does not detail tab defaults or the exact result structure.

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 sentence that front-loads the core behavior and packs in the bounded-step ceiling, per-step extraction, nested container option, and early-stop condition. Every clause adds value and there is no wasted wording.

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

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

The tool is complex with 12 parameters, nested objects, and no output schema. The description explains the main flow but omits the full result contract beyond stoppedReason, noNewItemsForSteps semantics, and guidance on dedupeBy or maxItems. It is adequate but not complete for fully correct invocation.

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

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

Schema coverage is only 58%, and the description adds useful relational meaning for steps, until, extract, and scroll (e.g., 'hard ceiling when until is set'). However, many parameters such as dedupeBy, maxItems, after, tabId, delayMs, documentId, and sessionTabId are left to the schema or remain undocumented by 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?

The description uses a specific composite verb phrase: scroll bounded steps, extract selected elements each step, optionally target a nested scroll container, and stop early via until conditions. This makes the tool's purpose clear and distinguishes it from simpler siblings like scroll or extract_elements.

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 clearly implies the use case: repeatedly scrolling a page while collecting matching elements across steps, with bounded steps and optional early termination. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to decide when this composite tool fits.

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 discloses only that logs are 'bounded' and captured after injection, but does not state whether reading logs clears them, what the bound means, how filtering works, or what happens when no logs exist. There is no annotation contradiction because none are provided.

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 filler. It front-loads the core action and the additional injection-context clause 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?

Given no output schema and no annotations, the description is too sparse for an agent to invoke the tool confidently. Missing details include the shape of returned log entries, how 'bounded' is determined, accepted levels values, and any stateful effects of calling the 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 only 60%; the 'limit' and 'levels' parameters have no schema descriptions, and the tool description does not clarify them. 'Bounded' weakly hints at the limit parameter but does not explain default or maximum behavior, and valid values for 'levels' are entirely left to inference.

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 and resource: 'Return bounded console logs.' The temporal scope ('captured after the content script was injected in the target tab') adds useful specificity. However, it does not explicitly differentiate from sibling inspection tools, though none are log-specific.

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

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

No guidance is given on when to use this tool versus alternatives, nor are any exclusions or sibling references provided. The only contextual hint is the mention of content-script injection and target tab, which implies a use case but does not make it explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'safer alternative' and 'bounded structured data,' hinting at safety and structure but not explicitly stating read-only behavior, side effects, or permissions. It does not disclose what happens with the extracted data, whether mutations are possible, or any constraints like rate limits. This is insufficient for a data-extraction 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 a single, efficient sentence that front-loads the core purpose and the safety differentiator. There is no redundancy or filler. While it is brief, conciseness itself is a strength; the lack of depth is penalized under other dimensions, not this one.

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 complexity (10 parameters, no output schema, no annotations), the description is severely incomplete. An agent cannot infer the return format, how to handle pagination or limits, what the include* flags control, or any side effects. The description provides only a high-level overview and leaves critical operational details undefined, making it inadequate 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 coverage is only 30%, so the description must compensate by explaining parameter meanings. It only clarifies that the selector is a CSS selector and that extraction yields structured data, which relates to the selector and output but not to flags like includeHtml, includeText, limit, or visible. The description adds minimal value over the schema and fails to cover the majority of parameters that the schema leaves 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 ('Extract'), a resource ('elements selected by CSS selector'), and a clear scope ('bounded structured data'). It also distinguishes itself from raw JavaScript evaluation by claiming to be a safer alternative, which separates it from a generic scripting tool. Even without naming a sibling explicitly, the purpose is unambiguous and easily differentiated from other tools like query_elements.

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

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

The description implies a usage context: use this instead of raw JavaScript evaluation for safer data extraction. However, it does not explicitly state when to use it versus other extraction tools (e.g., query_elements), nor does it mention exclusions or prerequisites. The single alternative mention provides only weak guidance, leaving the agent to infer the rest from sibling names.

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 fully disclose behavioral traits. It mentions that it extracts structured records, but it does not describe important behaviors such as pagination handling, limits, whether it mutates the page, or what happens if no feed is found. The description is also silent on permission requirements (e.g., claiming tabs) even though related tools exist. This is a significant gap for a tool that likely interacts with the browser state.

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

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

The description is very concise, a single sentence that captures the core purpose. It front-loads the key output and differentiator. However, it could be more structured by separating purpose from usage hints, but it is adequately sized for a tool with a rich schema.

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 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain how the extraction behaves with respect to the scope parameter, or any side effects. It doesn't clarify what happens with 'live flags' or how times are formatted. An agent would need to guess many details from the schema alone, making it incomplete for a full understanding.

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

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

The schema has 100% description coverage, so each parameter is documented. The tool description adds minimal extra meaning beyond 'structured feed/post records'. The schema covers the semantics of each parameter, so the description does not need to repeat it)Skip. However, the description could add context on how parameters like 'scope' interact with feed extraction, but that is not present, so it is at baseline.

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

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

The description clearly states the tool's purpose: to extract structured feed/post records (author, text, times, live flags) from a scoped feed region. It also distinguishes it from other extraction tools like extract_elements by mentioning 'without site-specific selectors' and 'structured feed/post records'. However, it does not name a specific sibling to differentiate from, and the purpose is somewhat narrow to feeds, which is clear but not maximally distinctive.

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 feed extraction, but it does not provide explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like extract_elements or visible_snapshot for cases where site-specific selectors are needed. The context of 'without site-specific selectors' hints at the use case but does not fully explain the trade-offs.

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 states that the tool releases ownership, does not close tabs, and detaches CDP attachments on all claimed tabs, including kept claims. It also clarifies that 'keep' entries preserve handoff/deliverable claims. This is transparent and covers key side effects, though it could mention reversibility 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?

The description is two sentences, front-loading the primary action. It is compact and each sentence adds relevant information: the main effect, a critical exception (no tab close), and a behavioral detail (CDP detach). No fluff or repetition, though it could be slightly more structured.

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 (one optional parameter, no output schema), the description covers the essential operational details: what it does, what it preserves, and what it detaches. It does not specify the scope of 'claimed tabs' (e.g., session-wide), but sibling tools like 'claim_tab' provide context. The absence of output schema is acceptable since no return value is defined.

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 description coverage is 0%, so the description must compensate. It explains that 'keep' preserves handoff/deliverable claims, which adds meaning beyond the schema. However, it does not elaborate on the 'status' enum values or the significance of 'sessionTabId', nor does it specify that 'keep' is optional. While it partially compensates, some parameter semantics remain implicit.

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: releasing browser-control ownership state for claimed tabs. It also specifies what it does NOT do (does not close user tabs) and that it detaches CDP attachments. However, it does not explicitly differentiate from the sibling tool 'release_tab', so an agent may need to infer the difference. Still, the core 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?

No guidance is given on when to use finalize_tabs versus release_tab or cdp_detach. The description does not mention typical scenarios, prerequisites, or conditions that would lead an agent to choose this tool over alternatives. It only describes the mechanism, not the context of use.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions that browser/OS shortcuts are not guaranteed under MV3 and that it fails with DOCUMENT_HIDDEN unless allowHidden=true, which adds useful context. However, it does not describe the return value, side effects, or whether the action is destructive, leaving significant gaps for a mutation 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 two sentences with no waste, front-loading the primary action and then providing key behavioral caveats. It is appropriately concise and efficient for an agent to parse.

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

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

The description omits critical context for correct usage: it does not explain the 'after' parameter for act-then-observe, how to specify key combinations or modifiers, or when to prefer this over sibling input tools. Given the tool's complexity and the absence of an output schema, the description leaves agents under-informed about its full capabilities and 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 description coverage is 83%, so most parameters are documented in the schema. The description adds minimal parameter insight—only the allowHidden behavior is echoed in the error mention. Since the schema already explains allowHidden in detail, the description does not meaningfully enhance parameter understanding beyond the structured data.

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 dispatches common DOM keyboard events in the target page, which is a specific verb and resource. It distinguishes from sibling tools like click and type because it focuses on keyboard events, but it does not explicitly name alternatives or differentiate further. Thus, it is clear but lacks sibling differentiation.

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

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

No guidance is given on when to use this tool versus alternatives like type or click. The only usage-related note is about the DOCUMENT_HIDDEN failure condition, which is a behavior, not a decision rule for tool selection. There is no mention of scenarios that favor keypress over other input 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 transparency burden. It does disclose a useful behavioral trait: blocked or unsupported frames are redacted and cannot be targeted, and 'current' implies a snapshot-style read. However, it leaves 'allowed target tab' undefined and does not explain failure modes, authorization prerequisites, or what side effects (if any) occur, which are notable gaps for a no-annotation 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 efficient: two sentences, the action comes first, and the second sentence adds the only redaction detail an agent needs. There is no redundant padding; every clause contributes a distinct aspect of the tool's behavior.

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

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

The tool has only two optional parameters and full schema coverage, so it does not need exhaustive explanation of inputs, but it leaves important operational details unaddressed: it does not describe the expected return shape of 'frame documents', the meaning of 'allowed target tab', or error behavior when no tabs are allowed. These gaps are moderate for a seemingly simple listing tool.

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

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

Schema description coverage is the 100% and each parameter's meaning and default behavior is already documented in the schema. The description adds no further parameter-level detail beyond the notion of an 'allowed target tab', which stays aligned with the schema but does not enhance it.

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

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

The description states a specific verb ('List') on a concrete resource ('current frame documents') and scopes it to 'an allowed target tab', which clearly distinguishes it from tab-level tools like list_tabs. The added note that blocked/unsupported frames are redacted further clarifies what the tool exposes.

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 context about targeting tabs through the phrases 'allowed target tab' and 'redacted... cannot be targeted', but it never explicitly says when to prefer this tool over alternatives like list_tabs or snapshots. Usage is implied rather than direct, with no exclusion criteria or sibling comparisons.

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 only states the scope ('visible to extension') but does not disclose whether the operation is read-only, what the output format looks like (e.g., tab IDs, URLs, titles), or any side effects. An agent cannot infer if this is safe to call repeatedly or what data it returns.

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, front-loaded sentence with no filler. It immediately states the action and scope, and every word adds value. This is a model of conciseness for a simple 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 simplicity (no params, no output schema), the description is somewhat adequate but leaves a key gap: it does not specify what the returned list contains (e.g., tab IDs, URLs, titles). Since there is no output schema, the description should at least hint at the return format for the agent to use the results effectively. Additionally, it could mention common use cases (e.g., enumerating tabs before claiming one) to improve decision-making among many siblings.

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

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

The tool has zero parameters and the schema has no properties, so there is nothing to describe. Per the baseline for 0-parameter tools, a score of 4 is appropriate since the description is not required to explain parameters. However, it does not add any supplementary detail about parameters because none exist.

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

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

The description clearly states the verb 'List' and the resource 'tabs', and adds useful scope constraints ('visible to the Chrome Browser Control extension', 'current Chrome profile'). This differentiates it from siblings like list_frames (frames vs tabs) and claim_tab/release_tab (management actions). An agent can immediately know the tool's core function without 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 implies the tool is used to enumerate tabs within the extension's visibility, but it does not explicitly state when to use this over alternatives like snapshot, visible_snapshot, or page_status. It lacks guidance on prerequisites (e.g., whether a session must be named) or complementary usage (e.g., before claiming a tab). The context is clear but exclusions are absent.

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 states that the name is used for status, logs, and debugging, which gives some side-effect insight beyond the parameter value. However, it does not state whether the name is persisted, overwritten, or how it appears in fragmented contexts, leaving some behavioral 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 a single highly readable sentence that front-loads verb the object and purpose. No wasted words or filler, and maximum clarity per word.

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 very simple tool with a single parameter and no output schema, the description is adequate to let an agent know what the tool does and what the parameter means. It doesn't discuss response-derived behavior, but the absence of output schema and the trivial complexity make the description almost complete, only revealing no details about overwriting or querying the current session name.

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

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

The schema provides no property descriptions (0% coverage), so the description must compensate. It does clarify that the 'name' is a human-readable identifier used for logs/status/debugging, and the parameter name 'name' aligns with this. Yet it does not explain any formatting constraints or examples in detail beyond the schema's min/max length.

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 ('Set') and resource ('browser-control session name'), and states the purpose ('for status, logs, and debugging'). It clearly distinguishes from sibling tools like browser_status or navigate by identifying the action of naming a session, with no ambiguity that it is a setter rather than a getter or mutating action.

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 explicit when/where comparison to sibling tools. The description implies use 'for status, logs, and debugging', which faintly guides context, but no exclusions are provided. An agent may infer to use this when a readable label is needed, but it does not force or avoid any 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?

The description discloses important behavioral traits: it does not activate a background tab by default and does not deactivate the focused tab, and it explains when to pass active: true. Since no annotations are provided, the description carries the burden and does a good job of clarifying side effects around tab focus.

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-loads the core action, and immediately clarifies the key behavioral nuance (focus handling). Every sentence earns its place with no wasted words.

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

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

For a navigation tool with a rich schema (after, waitFor, snapshot, pageStatus), the description covers the essential behavior and focus semantics. It doesn't explain return values, but there is no output schema and the tool's primary purpose is clear. The nested 'after' options are well-documented in the schema, so the description doesn't need to repeat them.

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%, so the schema already documents most parameters. The description adds meaning by explaining the default focus behavior and the active parameter's purpose, but it does not elaborate on the 'after' object or tabId/sessionTabId semantics beyond what the schema provides. Baseline 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 states a specific verb ('Navigate') and resource ('active tab or target tab to a URL'), and distinguishes itself from sibling tools like activate_tab by clarifying focus behavior. It clearly identifies what the tool does and its scope.

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 (navigating a tab to a URL) and explains the default focus behavior, which helps an agent decide when to pass active: true. However, it does not explicitly mention alternatives or when not to use it, such as when to use click or type instead.

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

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

With no annotations, the description must carry all behavioral disclosure. It mentions 'lightweight' and 'allowed target tab' but does not clarify permission requirements, whether the operation is read-only, failure modes, or any side effects. The brevity leaves significant behavioral 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 a single sentence that front-loads the primary purpose and then lists the returned elements. It is concise and free of fluff, though it could arguably include a bit more contextual detail without losing efficiency.

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

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

Given the absence of annotations and an output schema, the description is incomplete for an agent to confidently call the tool. It does not explain the return format, prerequisites like claiming a tab, or error conditions, leaving important operational details unspecified.

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% and each parameter (tabId, documentId, sessionTabId) has a descriptive string in the schema. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline score 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 states a specific action ('Return lightweight page status') and names the specific data included (viewport/scroll state, resource summary counts) for an allowed target tab. This is clear and distinguishes it from general snapshot tools, though it doesn't explicitly contrast with browser_status.

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

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

There is no guidance on when to use this tool versus siblings like browser_status or snapshot. It does not mention prerequisites (e.g., needing a claimed tab) or scenarios where this tool is preferred, leaving the agent to infer usage from the 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?

With no annotations, the description carries the full burden. It discloses fail-fast behavior, DOCUMENT_HIDDEN failure for click/type/keypress unless allowHidden=true, and documentId revalidation before every step and after observation. This is substantive behavioral context beyond the schema, though it does not cover scroll-specific behavior or return values.

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 sentences with zero redundancy. The main purpose is front-loaded, and each subsequent sentence adds a critical behavioral constraint. It is compact and well-structured.

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

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

The description covers the core behavior (batch execution, fail-fast, hidden handling) but does not mention the 'after' observation feature or other parameters like tabId/sessionTabId. However, those are fully described in the schema, and the description provides enough high-level context for an agent to understand the tool's primary function and constraints.

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 baseline is 3. The description adds meaning beyond the schema by explaining documentId revalidation (steps cannot override it) and the allowHidden exception for hidden documents. These nuances are not present in the parameter descriptions themselves.

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: 'Run up to 10 sequential page actions in one document target.' It clearly distinguishes this from sibling tools like click/type/scroll by emphasizing batch execution and the single-document constraint. The mention of fail-fast and DOCUMENT_HIDDEN behavior further clarifies its role.

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

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

The description implies this is for batching multiple actions, but it does not explicitly contrast with single-action siblings (click, type, scroll) or state when to prefer this tool over them. The documentId revalidation and hidden-document notes give some context, but no explicit 'use this for multiple actions; use click for a single action' 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?

Annotations are absent, so the description carries the full disclosure burden. It does add one useful behavioral trait by explaining the tool does not return full page text, which prevents a reasonable misunderstanding. However, it does not state whether the tool is strictly read-only, what the return shape is, whether it waits for page content, or how it handles pages with no matching elements, leaving the agent to infer important behavioral traits.

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 one short sentence with no filler, and the meaningful behavioral constraint 'without returning full page text' is included. It loses one point for restating the title's basic purpose before adding the new information, but it is still concise and 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?

Given 8 mostly optional parameters and no annotations or output schema, the description is minimal and does not fully define how the tool behaves at the boundaries. It does not explain how selector, role, text, and visibility relate to one another, what the returned elements look like, or what constraints exist around tab/session/frame addressing.

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 38%, so the description should compensate for undocumented parameters. It covers four of them by listing 'selector, role, text, and visibility', which gives semantic meaning to `selector`, `role`, `text`, and `visible`. It does not explain how multiple criteria interact (e.g., AND or OR) and says nothing about `limit` semantics, so parameter behavior is only partially defined.

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

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

The description states a specific verb ('Find'), a specific resource ('elements'), and explicit search dimensions: 'selector, role, text, and visibility'. It also adds a discriminating constraint, 'without returning full page text'. It is clear what the tool does, though it does not name a sibling tool (e.g., extract_elements or visible_snapshot) so an agent must infer the exact boundary.

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 explicit guidance about when to use this tool versus alternatives such as extract_elements, visible_snapshot, or wait_for. No usage condition, prerequisite, or 'use this when X' is provided. The only hint is the negative 'without returning full page text', but no direct comparison or sibling differentiation 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?

Without any annotations, the description carries full responsibility for disclosing behavior. It mentions that the tab is not closed, which is a useful side-effect, but it does not explain what 'release' does to the claim state, whether the operation is idempotent, or any other implications. This is a minimal disclosure given the absence of structured behavioral 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 a single, front-loaded sentence with no waste. It states the action, the resource, the identifiers, and the key behavioral qualifier, all efficiently without redundancy.

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

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

For a tool with no annotations and no output schema, the description is bare-bones. It covers the main action and identifier options, but omits preconditions, detailed side effects, and error behavior. While the tool is simple, an agent might need more detail to act safely and correctly.

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

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

With 0% schema description coverage, the description adds meaning by stating that the tab can be identified by sessionTabId or tabId, clarifying that these are alternative selectors. It does not explain each parameter's exact role or priority, but it provides more than the schema alone.

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-resource pair, 'Release a previously claimed tab', distinguishing it from claim_tab and other tab management tools. It also specifies the identifiers used (sessionTabId or tabId) and the critical side-effect constraint that the browser tab is not closed, clearly conveying the tool's function.

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 phrase 'previously claimed tab' implies the tool is used after a tab has been claimed via claim_tab, but it does not explicitly state this condition or compare with alternatives. No explicit when-not-to-use or alternative routing is provided, leaving usage to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states that the tool only captures the visible tab viewport and that iframe frameViewport bounds are invalid, which are key behavioral traits. It also mentions cropping options. While it does not state permissions or side effects, for a screenshot tool these are less critical. The description adds meaningful context beyond 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?

The description is three sentences, each with a clear purpose: the core action, a critical constraint, and cropping options. It is front-loaded with the main purpose and avoids redundancy. Every sentence earns its place, making it highly efficient and easy to parse.

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 6 parameters, a nested object, and no output schema, the description covers the main behavior, the iframe limitation, and the cropping options. It does not explicitly state the output format, but that is implied by the tool name and the schema. It also does not mention what happens when no ref or bounds are provided, but 'Capture the visible tab viewport' implies a full viewport capture. The description is sufficient for an agent to call the tool correctly in most scenarios.

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 most parameters are already documented. The description adds value by clarifying the semantics of ref and bounds: 'top-document snapshot ref' and 'tabViewport bounds' explain the coordinate system and cropping targets. It also reinforces the mutual exclusivity of ref and bounds by presenting them as alternatives. This goes beyond the schema's terse 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 states a specific verb and resource: 'Capture the visible tab viewport.' It also includes a scoping constraint ('tab-target only') and a caveat about iframe coordinates, which clearly distinguishes it from potential sibling tools that handle full-page or iframe captures. This is not a tautology and provides a precise 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 gives clear context for when to use the tool: it is tab-target only and iframe frameViewport bounds are not valid crop coordinates. This implicitly tells the agent not to use it for iframe captures, and it suggests using it with a top-document snapshot ref or tabViewport bounds for cropping. However, it does not explicitly name alternative tools like snapshot or visible_snapshot, so the guidance is strong but not exhaustive.

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 behavioral burden. It discloses coordinate frame semantics, iframe targeting, and the lazy-load limitation, which is meaningful. It does not mention side effects, scroll-triggered events, permissions, or what the tool returns after execution.

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 dense sentences with no filler. The primary action and target are front-loaded, and the follow-up sentences add high-value coordinate and lazy-load caveats. Every sentence 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?

The description plus the rich schema cover target selection, coordinate spaces, snapshot options, wait conditions, and the key lazy-load caveat. The main gap is the absence of an output schema and no explicit contrast with collect_scroll, but the agent has enough to invoke the tool correctly.

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 75%, so the baseline is already moderate. The description adds important semantic detail beyond the schema, especially that x/y are tabViewport coordinates for the top document and frameViewport coordinates for an iframe, and clarifies documentId targeting. Remaining parameters are already well described in the schema.

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

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

The description clearly states the action ('Scroll') and the resource ('current top document or an exact documentId') with pixel-delta detail. It doesn't explicitly differentiate from sibling collect_scroll, but the target and coordinate nuance make the purpose unambiguous.

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

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

The description gives a useful condition for effectiveness: 'scroll only helps when the page lazy-loads content' and suggests using textLimit on snapshots to capture more text. However, it does not name specific alternatives or give explicit guidance on when another tool like collect_scroll would be more appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it explains default scoping behavior (main landmark vs visible modal), default truncation limits (500/4000), the fact that textLimit is not a hard cap, and that the response includes 'authoritative document identity and coordinate space.' It also discloses that compact mode returns textPreview only, not text. The only minor gap is not describing the exact response shape or error conditions, but the description covers the most important behavioral traits.

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 dense but well-organized, front-loading the core purpose and then layering mode, scope, and limits. Every sentence adds information, and the structure mirrors the parameter hierarchy (mode → scope → textLimit → documentId). It is long, but the complexity of the tool (8 parameters, modal scoping rules) justifies the length. A slight trim could improve scannability, but it is not bloated.

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

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

Given the tool's complexity (8 parameters, modal scoping, truncation, frame targeting), the description is remarkably complete. It covers defaults, edge cases (modal dialogs, legacy document scope), and the source of key identifiers (list_frames, claim_tab). There is no output schema, so the description's mention of 'authoritative document identity and coordinate space' gives a useful hint about the return value. It could mention error cases or the exact response structure, but for an agent deciding whether and how to call this tool, the description is sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the interaction between scope and ignoreRoles (e.g., 'A visible non-modal dialog is included without taking scope; a visible modal takes scope'), and by clarifying that textLimit defaults differ by mode. It also explains the relationship between documentId and list_frames. This goes beyond the schema's per-parameter descriptions, so a 4 is warranted.

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 specific verb and resource: 'Return a simplified DOM snapshot for the current top document or an exact documentId from list_frames.' It clearly distinguishes the tool from siblings like visible_snapshot and query_elements by describing the snapshot's purpose and modes. The title 'Snapshot active page' is also expanded with concrete detail about what the snapshot contains.

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 explains when to use compact vs full mode, when to pass scope: 'document' for legacy full-body text behind a modal, and when to use ignoreRoles to hide dialogs. It also names list_frames as the source for documentId and claim_tab for sessionTabId, giving clear context for when those parameters are needed. This is strong routing guidance that helps an agent choose the right invocation.

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. It discloses two important failure modes (password fields blocked unless force=true; DOCUMENT_HIDDEN unless allowHidden=true) and names activate_tab as a remedy. It does not mention other behaviors like whether the text replaces existing content or appends, but the disclosed constraints are valuable and specific.

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 with zero waste. The core action is stated first, followed by the two most important behavioral constraints. Every sentence 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 tool with 8 parameters and no output schema, the description is reasonably complete. It covers the core action and the two main failure modes. It does not explain the 'after' observation block or the tab/frame targeting semantics, but the schema provides descriptions for those. The description is adequate for an agent to invoke the tool correctly in most cases.

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

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

Schema description coverage is 63%, so the schema already documents many parameters. The description adds meaning for 'ref' (snapshot ref) and 'force' (bypass password blocking), but does not explain 'after', 'tabId', 'documentId', or 'sessionTabId' beyond what the schema provides. The description adds some value but does not fully compensate for the undocumented parameters.

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 ('Type'), a resource ('text into an element by snapshot ref'), and two key behavioral constraints (password fields blocked unless force=true; DOCUMENT_HIDDEN unless allowHidden=true). It clearly distinguishes this from sibling tools like click, keypress, and click_at, which involve different interaction mechanisms.

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

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

The description implies usage context: it is for typing text into an element, and it explicitly mentions when it fails (password fields, hidden documents) and the remedy (activate_tab). It does not explicitly name alternatives like keypress for keyboard events, but the context is clear enough for an agent to select this tool for text entry.

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 disclose behavioral traits. It adds useful context about viewport-awareness and that iframe bounds use frameViewport coordinates, which is a specific coordinate system note. However, it does not mention read-only nature (though implied), potential performance costs, pagination, or what happens when no visible elements exist. It is not misleading, but it leaves some behavior unspecified.

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

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

The description is two sentences with no wasted words. The primary function is front-loaded in the first sentence, and the coordinate detail is a concise second sentence. Every word adds value, making it an efficient and well-structured description.

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

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

The tool has four optional parameters and no output schema, so the description must explain what the agent receives and any constraints. It lists the returned content types and notes the coordinate system, which is helpful. However, it lacks usage context (when to prefer this over 'snapshot'), does not mention any limits or pagination, and does not describe the response format. Given the moderate complexity and lack of output schema, the description 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 75% (three of four parameters have descriptions; 'limit' does not). The description itself adds no parameter-specific meaning, but it is not required to since most parameters are already documented in the schema. The missing 'limit' description is a gap, but the description does not attempt to compensate. Given moderate coverage, the baseline is a 3.

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

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

The description clearly states the tool returns a viewport-aware snapshot and enumerates its contents (visible/intersecting elements, refs, labels, roles, bounds, scroll metadata). The verb 'Return' and resource 'viewport-aware snapshot' are specific. It distinguishes itself from a generic 'snapshot' by emphasizing viewport-awareness, though it does not explicitly name the sibling 'snapshot' tool or contrast them.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'snapshot', 'query_elements', or 'extract_elements'. It does not mention use cases, exclusions, or conditions that would select this tool over others. An agent would have to infer usage from the tool name and description alone, which is insufficient given the sibling list.

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 state what happens on timeout, whether the tool throws or returns a value, whether it blocks or polls, or any side effects. The phrase 'bounded content stability' is opaque without further explanation. This is a significant gap for a waiting tool where agents need to know failure 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 a single sentence that front-loads the full list of wait conditions. It is efficient and information-dense, with no filler. Every word contributes to the core purpose.

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 13 parameters, many with complex interplay (e.g., scope, ignoreRoles, excludeSelectors), yet the description only summarizes the wait types. It does not explain return behavior, timeout semantics, or how parameters interact. Without an output schema, the agent lacks crucial information to call this correctly in diverse scenarios.

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 69%, with several parameters lacking descriptions (text, selector, timeoutMs, urlIncludes, documentId). The description provides a high-level summary of the wait conditions, which partially aligns with parameters, but it does not elaborate on parameter meanings or combinations beyond the schema. It adds some value by grouping conditions but does not fully compensate for the uncovered parameters.

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 clear verb ('wait for') and enumerates the specific conditions it handles: text, selector, URL substring, selector absence, scoped text, and bounded content stability. It is specific and unambiguous, and since no sibling tool performs waiting, it distinguishes itself effectively.

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 waiting on page conditions but does not explicitly state when to prefer this tool over alternatives or when not to use it. It also lacks guidance on which parameter combinations are valid (e.g., can text and selector be used together?). The context is clear but exclusions and selection criteria are absent.

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