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 the exact data cleared for each scope, notes that 'all' wipes profile-wide HTTP cache and all cookies, and mentions time-bounding. It doesn't explicitly state destructiveness, but the actions imply it. This is strong transparency for a state-clearing 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 efficient and well-structured, leading with the purpose and then explaining scope logic and defaults. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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's complexity is moderate due to scope-dependent behavior and session-type variations. The description covers the key decision points (scope selection, defaults) and notes time-bounding. It omits details like error handling or cross-tab effects, but these are minor given the tool's straightforward purpose. Overall, it provides sufficient context for 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?

The 'scope' parameter is thoroughly explained in the description, adding meaning beyond the schema's bare enum and default. However, 'sessionId' is not described in either the schema or the description, leaving its purpose and format ambiguous. With 50% schema coverage, the description compensates for scope but not sessionId.

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 clears browsing state, specifies exactly what is cleared (cookies, storage, cache, service workers) and distinguishes between the two scopes. It is specific, actionable, and differentiates from siblings like browser_hard_reload.

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

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

It explicitly states when to use the tool ('before a run that must start clean') and provides detailed guidance on choosing between 'origin' and 'all' based on session type (fresh vs attach). It also clarifies default behavior, which is critical for correct usage.

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

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

With no annotations provided, the description carries full burden of behavioral disclosure. It implies a destructive action (closing sessions) but does not mention irreversibility, impact on the current session, or whether closing all sessions has any side effects like terminating the browser. This is a significant gap for a destructive operation.

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

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

The description is a single, concise sentence with no wasted words. It is front-loaded with the core action, but the brevity sacrifices necessary detail. It earns points for being succinct, though it under-specifies.

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

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

The tool has two parameters, no annotations, and no output schema. The description does not clarify the relationship between sessionId and all, what happens after closing, or any expected return values. For a destructive operation with minimal structured context, the description is insufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'all=true' but does not explain the sessionId parameter, whether it is required, or how it interacts with all. The description adds minimal meaning beyond the schema, leaving parameter usage ambiguous.

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

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

The description states a clear verb ('close') and resource ('session'), and specifies the scope with 'all=true' to close all sessions. It is specific enough to distinguish from sibling tools like browser_close_tab, which targets tabs rather than sessions.

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

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

No guidance on when to use this tool versus alternatives. It only explains the all flag but does not mention when closing sessions is appropriate, prerequisites, or exclusions. The description is purely functional with no context about typical use cases.

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 that only one tab is closed, the session remains open, closing the driven tab triggers healing onto another live tab, and the tool refuses to close the last tab. This is substantive behavior beyond what the schema shows.

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, each earning its place: the core operation is front-loaded, the healing behavior is stated, and the refusal rule routes to the correct sibling. There is no fluff or repetition of schema details.

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 single-tab close operation with no annotations and no output schema, the description is nearly complete: it covers scope, session behavior, edge-case refusal, and alternatives. It only omits explicit handling of invalid indices or mention of the optional sessionId parameter, but the core calling context is well covered.

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

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

The schema has 0% description coverage, so the description must compensate. It does clarify that index refers to a tab position from browser_tabs, but it never mentions the optional sessionId parameter, leaving that parameter's semantics 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 opens with a specific verb and resource: 'Close ONE tab by index (from browser_tabs) without closing the session.' It clearly distinguishes this tool from browser_close by stating it does not close the session and names browser_tabs as the source of the index, so an agent can tell it apart from sibling tools.

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

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

It gives explicit use cases: 'drop a finished game's tab' or 'close the opener so the game tab is the only one left.' It also states when not to use it and points to the alternative: 'Refuses to close the last remaining tab — browser_close the whole session for that.'

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 behavioral disclosure burden and covers key traits: cache bypass, acceptance of beforeunload prompts so the reload actually happens, and the reported output. It omits potential details like whether it waits for load completion or clears cache, but overall it 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?

Three tight sentences, each adding distinct information: the core action, the beforeunload handling, and the return values. No filler, repetition, or unnecessary details.

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 low-complexity tool with no annotations or output schema, the description adequately explains the action, a key behavioral nuance, and the return value. The main gap is the undocumented sessionId parameter, but the tool remains invocable with no required parameters.

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

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

Schema description coverage is 0% and the description never mentions the sessionId parameter. The agent only gets the parameter name and optionality as a clue; there is no guidance on when to pass it or what session is used by default.

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

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

Description states a precise action ('Reload the page bypassing cache'), gives a familiar user analogue (Cmd+Shift+R), and specifies the output (reloaded page's url and title). This clearly distinguishes it from normal navigation tools like page_goto or cache-clearing tools like browser_clear_cache.

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 it (when a cache-bypassing reload is needed) via the 'hard refresh' analogy, but it does not explicitly contrast it with alternatives or state when not to use it. No sibling tool is named, leaving the agent to infer the appropriate context.

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

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

With no annotations provided, the description carries the full behavioral burden, and it excels: it discloses that fresh is a throwaway browser, attach connects to a debug-port Chrome, the launched session becomes active, fresh mode auto-follows new tabs, and only `port` applies in attach mode. It also reveals technical details like navigator.webdriver=false and viewport stability for mobile games.

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-structured with scannable bullets and front-loaded mode guidance. Every sentence adds operational value, including concurrency, active-session behavior, and mobile-game advice, without unnecessary repetition.

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

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

Given the tool's complexity, eight parameters, and no output schema or annotations, the description covers the essential operational context: how to select modes, prerequisites, limitations, session behavior, and game-specific guidance. An agent has enough information to invoke the tool correctly without additional research.

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

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

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains mode-specific parameter applicability, the default port, why `device:'mobile'` matters for games, and how `viewport` interacts with canvas/WebGL letterboxing. This materially improves an agent's ability to choose 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?

States a specific action ('Open a browser session') and clearly differentiates the two modes it supports, fresh vs attach. The description makes it unambiguous what the tool does and how it differs from later navigation/session tools.

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

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

Provides explicit when-to-use guidance: fresh for public flows or sites not needing login, attach for real logins/cookies or human-like browser behavior. It also gives exclusions and prerequisites, such as 'You canNOT attach to an already-open normal Chrome' and needing `./bfa-chrome 9222` first.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals the two-step destructive/recovery behavior: terminating the running script, disabling page scripts, and re-enabling them via scripts:true. It also states that the tool reports which step worked, which is more than enough absent annotations.

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 carry the full purpose, procedure, parameters, reporting behavior, and fallback route. It is front-loaded with the core action and contains no filler or repeated schema information.

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

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

The tool has moderate complexity and no output schema, but the description covers the main procedure, the scripts toggle, and what the tool reports. The sessionId parameter and exact return structure are not detailed, so it is not fully complete, but it is quite close for a recovery tool.

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

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

The description adds meaningful context for the scripts parameter by tying it to the recovery flow ('call again with scripts:true to turn them back on'), but the sessionId parameter is not explained anywhere in the description. With schema coverage at 50%, the other parameter remains opaque, so this is only minimally sufficient.

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: 'Unfreeze a page whose JavaScript is pinned,' and clearly distinguishes this tool from the named sibling browser_close: 'If nothing helps, browser_close is bounded and force-kills an owned Chrome.' This leaves no ambiguity about what browser_recover 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?

It explicitly states the triggering condition ('tools timing out, tab unresponsive'), describes the recovery steps, explains how to re-enable scripts afterward, and names the fallback alternative (browser_close). This is strong when-to-use and alternative 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 must carry the behavioral burden. 'List' implies a read-only operation, but the description does not disclose output structure, whether the current session is included, or any edge behavior. It is not misleading, but it is minimal.

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 with no filler; the verb and scope are front-loaded. Every word earns its place.

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

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

For a zero-parameter listing tool, the description covers the essential action and scope. However, since there is no output schema, the description does not describe the shape or fields of the returned sessions, which is a minor gap.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds clarifying scope with 'all open', making it clear that no filters or arguments are needed.

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

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

The description uses a specific verb ('List') and resource ('all open browser sessions'), so the tool's core function is clear. It distinguishes itself from siblings like browser_tabs by targeting sessions rather than tabs, though it does not explicitly name or contrast any alternative.

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

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

There is no guidance about when to use this tool versus alternatives such as browser_tabs, session_restore, or browser_launch. The description only states what the tool does, leaving the agent to infer routing from the tool name and 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states only that the tool lists tabs/targets, leaving unexplained what 'targets' means, whether sessionId is required or defaults to the active session, what the response format is, and what happens when no session is available. This is minimally transparent for a read-only listing operation.

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

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

The description is a single concise phrase with no wasted words and is front-loaded with the primary action. It earns its place, though its brevity borders on under-specification rather than economical completeness.

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

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

The tool is simple, with one optional parameter and no output schema, but the description still fails to communicate essential context about sessionId semantics, return values, or how this listing relates to tab-management siblings. An agent would likely need to infer or experiment to use it 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 description coverage is 0%, and the description does not explain the sessionId parameter at all. 'Of a session' hints that a session identifier is relevant, but it does not clarify whether the parameter is optional, how it is formatted, or what happens if it is omitted. With no schema documentation, this is a significant gap.

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

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

The description states a clear action ('List') and a clear resource ('tabs/targets of a session'), which distinguishes it from sibling tab-manipulation tools like browser_close_tab or browser_use_tab. It does not explicitly contrast with those siblings, but 'list' and 'of a session' give a solid functional identity.

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

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

No guidance is given about when to use this tool versus alternatives such as browser_sessions, browser_use_tab, or page_state. The phrase 'of a session' provides mild context, but there is no mention of prerequisites, when this is the preferred tool, or what differentiates it from closely related siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose a meaningful state-changing behavior: it sets a session that other tools target by default. However, it does not mention what happens if the sessionId is invalid, whether the previous session is lost, or any 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 a single front-loaded sentence with no wasted words. It states the action and the consequence clearly and efficiently.

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 setter, the description covers the core behavior and the target state. It does not mention prerequisites like starting or listing sessions, but given the low complexity and the parameter name, an agent has enough information 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 description coverage is 0%, so the description must compensate for the undocumented parameter. The description only tells the agent that a session is being set; it does not explain how to obtain a sessionId or what format it should take. The parameter name 'sessionId' is self-explanatory, but the description adds little semantic value beyond 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 uses a specific verb ('Set') and resource ('active session'), and clarifies the effect: other tools target this session by default. It does not explicitly distinguish itself from sibling tools like browser_use_tab or browser_sessions, but the focus on session-level state is reasonably clear.

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

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

The description implies this should be called before using other browser tools, but it gives no explicit guidance on when to use this versus alternatives such as browser_use_tab or session_restore. There are no exclusions or alternative recommendations.

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 a non-obvious stateful behavior: switching carries 'the network/console recorder and any intercept rules across,' and that subsequent page_*/net_*/page_tap_at calls act on the newly selected tab. Minor response/error behaviors are not covered, but the key behavioral traits are disclosed.

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

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

Two dense but efficient sentences. The first front-loads the core action and its consequential state transfer; the second immediately clarifies the automatic-follow behavior and the targeted use cases. No filler or repetition.

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

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

For a tool with no output schema and no annotations, the description covers the essential operating context: how to reference the target tab, what state carries over, what subsequent tools will act on, and when the switch is needed. The undocumented optional sessionId is a minor gap, and error behavior is not described, but the tool is simple enough that the description is largely sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaningful context for the required 'index' by linking it to 'browser_tabs', but the optional 'sessionId' parameter is left unexplained in both the schema and the description, leaving a partial gap.

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

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

States the specific verb 'Switch' and the resource ('the session's DRIVEN tab'), with an explicit source for the index ('from browser_tabs'). The phrase 'page_*/net_*/page_tap_at then act on THAT tab' further disambiguates it from list-only or close-only sibling tools.

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

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

Gives explicit use cases: 'go back to the opener, or to drive a tab that wasn't opened by the page.' It also clarifies when the tool is not needed by explaining that bfa already auto-follows page-opened tabs, giving a clear when-not-to-use signal.

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 ordering and stack-trace behavior beyond the surface meaning of the name. However, it does not mention whether the operation has side effects, how session selection behaves when sessionId is omitted, or the shape of the returned data.

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

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

A single, tightly packed sentence front-loads the primary action and scope, then adds two specific behavioral details. Every clause earns its place and there is no redundant phrasing.

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 simple one-parameter list tool, so the description is mostly sufficient, but it leaves a few gaps: the sessionId parameter is not explicitly mapped, and with no output schema, the structure of the returned error/warning list is not described. The ordering and stack-trace inclusion help, but the definition could be stronger with a sentence about session selection and return format.

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

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

Schema description coverage is 0%, but there is only one parameter with a highly self-descriptive name, 'sessionId'. The phrase 'for a session' loosely connects to that parameter, but the description does not explicitly state that sessionId identifies the target session or that it is optional.

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 ('List') with a clear resource ('console errors and warnings') for an identified scope ('a session'). It adds precise behavioral details — ordering ('most-recent-last') and inclusion of the first stack-trace line — that distinguish it from the sibling console_list by narrowing to errors/warnings only.

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 (when you need console errors or warnings for a session) but does not explicitly contrast it with alternatives such as console_list or net_failures. There is no exclusion guidance or conditional routing, so the usage context is clear but implied rather than stated.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure and does well: it states the ordering (most-recent-last), filtering capability, default limit, and explicitly guarantees no silent truncation. It does not mention authentication, return format, or behavior for invalid regex/pattern input, but the core behaviors are transparent.

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

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

The description is a single, front-loaded sentence that packs the primary action, resource, ordering, filters, default limit, and truncation guarantee without wasted words. Every clause adds useful information.

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

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

The description covers the main list semantics but leaves the optional sessionId parameter ambiguous—an agent cannot tell whether omitting it defaults to the current session or fails. With no output schema, there is also no description of the returned entry shape, and the relationship to console_errors 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?

Schema description coverage is 75%, so the schema already documents level, limit, and pattern. The description reinforces these but adds little new parameter-level meaning; sessionId has no schema description and the description only refers to 'a session' without explaining the optional/default behavior. This matches the baseline for 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 action (List), the resource (captured console entries), the scope (for a session), and key behavior such as ordering and filtering. However, it does not explicitly differentiate this tool from the sibling console_errors, though the level/pattern filtering implies a broader 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 gives no guidance about when to use this tool versus alternatives like console_errors, nor does it mention prerequisites such as whether a sessionId is required or what happens when it is omitted. Usage context is only implied by the verb '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?

The description provides detailed behavior on dependency detection: what values get lifted to variables (verbatim from earlier responses), what stays literal (base64/encoded/JWT-internal, user-supplied literals), and a caveat about over-chaining. This is substantial transparency, especially since no annotations 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?

Two sentences: the first states the main purpose, the second details the detection algorithm. Both earn their place, though the second is dense. Efficient 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?

For a tool with no output schema, the description explains the window selection (flow_mark or whole buffer), the two output formats, and the dependency detection behavior. Missing sessionId semantics but otherwise complete for the tool's 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 covers 3 of 4 parameters with descriptions (format, sinceSeq, includeAll), and the description adds no parameter-specific details. sessionId lacks a description in both schema and description. Baseline 3 is appropriate given 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?

Clearly states the tool exports captured network calls as a JSON summary or HAR document, with specific mention of cross-call dependencies. This distinguishes it from siblings like net_list (which likely lists raw calls) and net_get (which retrieves specific calls).

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

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

No explicit guidance on when to use this tool versus alternatives like net_list or net_get. The mention of 'since the last flow_mark' implies a pairing with flow_mark, but there are no exclusions or alternative recommendations.

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 explains a meaningful side effect on downstream tools, but does not disclose whether the mark is persistent, overwrites previous marks, or is scoped to a session.

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 filler. The core action is front-loaded, and the downstream effect is stated compactly in the second sentence.

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

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

The core behavior is covered, but with no annotations and no output schema, the missing sessionId semantics and lack of detail about mark persistence or active-recording requirements leave some practical gaps for the agent.

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

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

Schema coverage is 50%: label has a description but sessionId does not. The tool description adds no parameter-level semantics, so sessionId remains opaque and the agent has to guess what it means.

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

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

The description uses a specific verb and resource: 'Mark the current point in the network recording as a flow's start.' It also distinguishes itself from related tools by explaining the relationship to flow_export and flow_synthesize, so an agent can tell exactly what this tool does.

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

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

The description gives clear usage context: flow_export and flow_synthesize default their capture window to calls recorded after this mark, implying flow_mark should be called before those tools. It does not explicitly state when not to use it, but the context is sufficient for typical 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 of behavioral disclosure, and it does so thoroughly. It reveals that replay is server-side, not in the browser session; that dependencies are resolved from live replay responses rather than the capture; that the return format is a compact per-call report; and it states safety limits (http/https only, 10s per-request timeout, 60s/200-step cap). This is unusually complete behavioral context.

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 dense block, but every sentence earns its place: core action, verification purpose, runtime dependency behavior, return format, and safety limits. It front-loads the main verb and resource before diving into details, and the use of a colon-separated return-format example is efficient. No fluff, no repetition.

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

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

Given the tool's complexity and the absence of an output schema, the description does an excellent job of explaining behavior, return format, and safety caps. Minor gaps remain: what happens when the 60s/200-step cap is exceeded, how sessionId selects the session, and how non-http URLs are handled (skipped vs. errored) are not stated. These are small relative to the rich context provided.

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 schema already documents three of four parameters; the description adds extra meaning by tying sinceSeq to the flow_mark window and by explaining the 60s/200-step overall budget around timeoutMs. The sessionId parameter is not covered in either the schema or the description, which is a small gap, but the added context meaningfully enriches the parameter semantics overall.

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 ('Execute') and a clearly bounded resource ('the captured network calls'), then narrows the scope with 'since the last flow_mark (or the whole buffer)' and 'server-side (Node fetch, NOT the browser session)'. It also states the verification goal ('this verifies a synthesized flow actually reproduces'), which distinguishes it from sibling tools like net_get or flow_export.

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

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

The description gives a clear when-to-use context: you run this after synthesizing a flow to check whether it actually reproduces against the server. It also clarifies that runtime dependency resolution catches broken reversed flows, which is a strong cue for choosing this over simple listing tools. It does not explicitly name alternatives or say when not to use it, but the intended workflow is unambiguous enough.

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 details dependency detection methods (exact, url-encoded, base64, JWT-claim, substring), explains that unmatched values stay literal for review, and warns about potential over-chaining. This is substantial behavioral disclosure, though it does not mention side effects or whether it mutates 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 a single dense paragraph that front-loads the purpose and then details dependency chaining. Every sentence adds value, and there is no fluff. It could be restructured with bullet points for the detection types, but it is efficient and appropriately sized for the complexity.

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 explains the core behavior well, but with no output schema, it does not explicitly describe the return value (the generated code) or any prerequisites (e.g., having captured calls). It implies the output by saying 'synthesize replay code' and the target enum, but it does not clarify whether the tool modifies state or what the code contains beyond variables. Some gaps remain for a complex 5-parameter 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 60% (redact, sinceSeq, includeAll have descriptions; target and sessionId do not). The description adds context about the window (since last flow_mark) and mentions 'whole buffer' which relates to sinceSeq, but it does not explain target (though enum values are self-explanatory) or sessionId. The description partially compensates for missing schema fields but not fully.

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 (synthesize replay code) with a clear resource (captured network calls) and lists the target languages (curl/TypeScript/Go/Python). It distinguishes itself from siblings like flow_replay (which likely executes code) and flow_export (which may export data) by focusing on code generation.

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: it operates on captured network calls since the last flow_mark or the whole buffer. It implies when to use it (when you need replay code) but does not explicitly exclude alternatives or mention when not to use it. There is enough context for an agent to understand its role among siblings.

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

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

With no annotations, the description carries the full burden. It usefully defines what counts as 'failed' (4xx/5xx or CDP-level) and promises error detail, which is real behavioral scope. However, it does not disclose whether listing consumes the failure buffer, is strictly read-only, or how session-scoped results behave — side-effect traits that matter in this tool family.

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?

One sentence, front-loaded with the verb and resource, with the criteria in a parenthetical. No filler; every word earns its place.

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

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

Adequate for a simple list tool: it defines the function and failure criteria. But with no annotations and no output schema, an agent cannot know the return shape beyond 'error detail', the role of sessionId, or how this tool differs operationally from net_list/net_pending. Minimum viable with clear gaps.

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

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

Schema description coverage is 50%: 'since' is well-documented in the schema, but 'sessionId' has no description anywhere. The tool description itself adds no parameter meaning beyond the schema and does not compensate for the undocumented sessionId.

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

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

States a specific verb ('List'), resource ('failed network requests'), and precise inclusion criteria ('4xx/5xx status or CDP-level failure') plus what is returned ('error detail'). This differentiates it from siblings like net_list (all requests) and net_pending (pending requests) without needing their schemas.

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 failure criteria and 'with error detail' imply when to use it, but there is no explicit guidance about when not to use it or which sibling alternatives (net_list, net_pending, net_get) apply to different diagnostics. In a family with eight net_* siblings, explicit routing would help.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return contents and the identification mechanism, but it does not mention edge behaviors such as what happens when both id and url are supplied, when neither is supplied, or when multiple requests match the url substring. The read-only nature is implied via 'Fetch' but not explicitly stated.

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, information-dense sentence that first states the action and result, then the identification method. There is no repetition of schema fields or annotations, and every 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?

For a straightforward retrieval tool with no output schema, the description adequately conveys what will be returned and how to choose the request. The main gaps are the undocumented sessionId parameter and lack of precedence/error behavior, but the core operational semantics are complete for an agent to invoke it 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 only 33% (only url has a schema description). The description compensates partially by explaining that id comes from net_list and url is a substring match, which adds real meaning. However, sessionId is completely undocumented in both schema and description, leaving a significant gap for one of the three 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?

States a specific verb 'Fetch' and resource 'one network request in full', enumerates the contents (headers, request body, response status/headers/body), and explains how to identify it (id or url substring). This clearly distinguishes it from sibling tools like net_list or net_pending, which list or filter requests rather than retrieve full detail.

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

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

The description tells the agent how to specify the target ('by id (from net_list) or a url substring'), which implies a workflow of listing first then fetching details. It does not explicitly name alternatives or state when not to use this tool, but the identification guidance provides clear usage context.

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

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

With no annotations, the description carries the full burden and adds meaningful behavioral context: it names the CDP Fetch mechanism, explains that urlPattern is a substring match, states that the first matching rule wins, and discloses lazy interception enablement. It does not cover rule persistence or session scoping, but the key behavioral traits are disclosed.

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

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

Three short sentences, each earning its place: the core action, the matching semantics, and the lazy-enable behavior. The most important information is front-loaded with 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?

Core calling behavior is well covered, but with no annotations, no output schema, and an undocumented sessionId, the agent is left to infer rule lifetime, session scope, and what the tool returns. The sibling net_intercept_clear implies persistence, but the description does not connect the two.

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

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

The schema already documents 5 of 7 parameters, and the description adds action-mode semantics and first-match ordering. However, sessionId is left entirely undocumented in both the schema and description, and the per-action parameter dependencies are only implied by the schema prefixes rather than explained.

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: 'Add a network intercept rule via CDP Fetch', then enumerates the three concrete behaviors (block, mock, modify). This clearly distinguishes it from listing or clearing intercept rules and from other network tools like throttling.

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 the tool applies: adding an intercept rule that can block, mock, or modify requests, with substring matching and first-match-wins behavior. It does not explicitly name alternatives like net_intercept_list or net_intercept_clear, but the usage context is unambiguous.

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 explains the key side effect—Fetch interception turns off when no rules remain and the page runs at native speed—and that adding a rule re-enables it. This goes beyond the tool name, though it does not address parameter requirements or error 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 concise sentence with a parenthetical that front-loads the core action and then adds the behavioral consequence. Every word adds value and there is no redundancy.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the main behavior and consequence. It lacks an explicit mention of the sessionId parameter and any edge cases, but the schema supplies the parameter name and type, so the overall context is nearly complete.

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

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

The schema documents a single sessionId parameter with 0% description coverage. The tool description only says 'for a session' and never names or explains the sessionId parameter, its requiredness, or its format. With low schema coverage, the description should compensate more but does not.

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

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

The description states a specific verb and resource: 'Clear all network intercept rules for a session.' The word 'all' and the session scoping clearly distinguish it from siblings like net_intercept_add and net_intercept_list.

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 behavioral context: interception is switched off once no rules remain and adding a rule re-enables it. This implies when to use the tool versus alternatives, though it does not explicitly name sibling tools or state exclusion conditions.

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 itself must carry behavioral disclosure. 'List active... rules' accurately conveys a read-only operation, but it does not explain what 'active' means, what happens when sessionId is omitted, or the output shape.

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 front-loaded sentence with no filler. Every word adds semantic content.

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

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

For a simple one-parameter list tool, the core operation is stated, but the absence of annotations and output schema leaves gaps around sessionId defaulting, return content, and relationship to sibling list/filter tools.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'for a session,' which maps loosely to sessionId but does not clarify that the parameter is optional, what value to pass, or what occurs when it is omitted.

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

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

States a specific verb ('List'), resource ('active network intercept rules'), and scope ('for a session'). The term 'intercept rules' clearly distinguishes this from network-list siblings like net_list and from mutation tools net_intercept_add/net_intercept_clear.

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

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

Provides no guidance on when to use this tool rather than net_list, net_intercept_add, or net_intercept_clear. There are no exclusions, prerequisites, or context cues beyond the phrase 'for a session.'

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

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

With no annotations, the description carries the full burden and does add real value: ordering ('most-recent-last'), a hard cap ('capped by limit (default 50)'), and the non-truncation guarantee ('never silently truncated'). However, it is silent on the return shape, session requirements, and whether this is a safe read-only operation.

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

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

Two sentences and roughly 20 words, with the verb+resource front-loaded, followed by ordering, then filters, then the cap guarantee. Every clause earns its place, and the non-truncation promise is stated without waste.

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

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

With no output schema and no annotations, the agent is left without knowledge of the result format, which matters for deciding whether to call net_get for details. The 8-parameter surface and the dense cluster of net_* siblings also warrant at least one sentence of cross-tool guidance, which is absent.

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

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

Schema coverage is 75%, so the schema already documents most parameters (type, limit, since, method, onlyXhr, urlIncludes), including the detailed enum semantics for 'since'. The description adds nothing beyond restating the limit default, and the two undocumented parameters (status, sessionId) remain unexplained — though they are fairly self-explanatory.

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 — 'List captured network requests for a session' — and adds useful detail like ordering ('most-recent-last'). It does not explicitly name sibling tools like net_get, net_failures, or net_pending, so differentiation is left to inference rather than stated.

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

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

The description offers no guidance on when to choose this tool over its net_* siblings (net_failures, net_pending, net_get, net_ws) or when not to use it. 'Filterable' hints at the filtering use case, but there are no exclusions, conditions, or alternative recommendations.

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

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

No annotations are provided, so the description carries the burden. It does disclose that the tool is a point-in-time read ('as of now') and scoped to in-flight requests, which is useful. It does not clarify whether the call blocks, whether websockets are included, or what happens when nothing is pending.

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 with no filler. The core action, scope, and purpose are front-loaded and every word contributes.

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 listing tool this is mostly adequate, but the lack of any output schema and the absence of sessionId semantics leave some gaps. An agent can infer returns from 'List network requests', but it cannot easily know how sessions are targeted.

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

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

Schema coverage is only 50%: the 'since' parameter has an enum and description, but 'sessionId' has no description beyond its type. The description itself mentions neither parameter, so it fails to compensate for the undocumented sessionId.

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 ('List'), a clear resource ('network requests'), and a precise state ('still in flight') with an explicit purpose ('candidates for a hang'). This clearly separates it from siblings like net_list, net_failures, or net_wait.

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 'candidates for a hang' implies this is for hang investigation, and 'as of now' signals a snapshot rather than a waiter. However, it does not explicitly state when to prefer this over net_wait or net_list, nor mention any exclusions or alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that only finished requests are included, orders them slowest first, and explicitly states the limit cap and that it is 'never silently truncated' – a useful behavioral guarantee. It does not mention read-only nature explicitly, but 'list' implies it, and no side effects are suggested. This adds meaningful behavioral context beyond a basic description.

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

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

The description is a single, well-structured sentence that front-loads the core purpose (list slow requests) and then provides essential defaults and behavior (cap, truncation). There is zero redundancy; every word contributes.

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 output schema, so the description should hint at the return structure, but it only says 'list' without describing item fields. It also omits any mention of sessionId, leaving its role ambiguous (optional vs. scoping). While the core behavior is clear, these gaps mean an agent may not know how to use sessionId or interpret results. Adequate but not 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 67% (limit and thresholdMs described, sessionId not). The description reiterates defaults for limit and thresholdMs but adds no new meaning beyond the schema; it also mentions the 'never silently truncated' behavior tied to limit. However, sessionId is completely unaddressed in both schema and description, leaving a gap. The description adds slight value but does not fully compensate for the missing sessionId semantics.

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

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

The description clearly states the specific action (list) and resource (finished network requests) with a precise filter (slower than a threshold). It distinguishes itself from sibling tools like net_list (all requests), net_failures (failed), and net_pending (pending) by specifying 'finished' and the threshold criterion, making the tool's 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 implies the tool is for retrieving slow finished requests but does not explicitly mention alternatives or when not to use it. No sibling tools are named, and there is no guidance on choosing between this and net_list or other net_* tools. The context is clear but lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes that the state persists across page_goto/reload until reset or session close, and that 'none' resets to full speed. This adds valuable context about side effects and persistence beyond the schema, though it does not address potential interactions with concurrent custom settings or return behavior.

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

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

The description is concise, consisting of two sentences that front-load the core purpose and then enumerate key options, default behavior, and persistence. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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 covers the main functionality well but leaves gaps: it does not clarify whether presets and custom throughput/latency can be used together, does not mention the sessionId parameter at all, and does not describe the return value or error conditions. These omissions could lead to incorrect invocation or unexpected behavior.

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

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

Schema description coverage is high (86%), so the baseline is 3. The description reinforces preset names and the max CPU factor, and clarifies the reset semantics of 'none'. However, it does not explain how preset and custom parameters interact (e.g., whether they are mutually exclusive or can be combined), and it completely omits the undocumented sessionId parameter, leaving that gap unaddressed.

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 emulates network and CPU conditions for a session via CDP, which is a specific verb and resource. It lists presets and custom options, distinguishing it from general network tools. However, it does not explicitly differentiate itself from the sibling 'net_slow', which might perform a similar function, so it misses an opportunity to clarify when this specific tool is needed.

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

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

The description explains how to use presets and custom parameters, but does not provide explicit guidance on when to choose net_throttle over alternatives like net_slow or net_intercept. It implies usage for throttling scenarios but offers no exclusions or direct comparisons to siblings, leaving the agent to infer the tool's niche.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It clearly reveals that the tool polls, waits at most timeoutMs, and matches only the first eligible request, but it does not disclose what happens on timeout or when no request matches—e.g., whether it throws, returns null, or returns partial data.

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

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

Two sentences, both purposeful: the first states the core behavior and default timeout, the second gives the motivating use case. No filler or 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?

There is no output schema and no annotations, so the description should clarify the result shape and timeout failure mode. It explains the waiting semantics well, but an agent cannot fully predict what the tool returns on success or does on timeout/no-match, which is essential for driving deterministic flows.

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 71%, so the schema already documents most parameter semantics and the baseline is 3. The description adds no extra meaning to method, status, sessionId, includeExisting, or requireFinished, and only restates the timeout default already present 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 conveys a specific action—poll captured network requests and resolve on the first match up to a timeout. It clearly states the verb, resource, and matching behavior, and implies a distinction from listing tools like net_list, but it does not explicitly name sibling alternatives.

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

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

It gives explicit usage guidance: use this instead of a fixed sleep to make driving deterministic, waiting for the actual request rather than guessing timing. It does not mention when not to use it or compare it to page_wait_for or net_pending, so it's clear 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, the description carries the behavioral disclosure burden. 'List' implies a read-only operation and the returned data (frame counts, recent frames) is stated, but the description is silent on whether sessionId scopes results, whether all sessions are included by default, or any limits on how many frames are returned.

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 with the action and resource front-loaded. It contains no filler or redundant restatement of the tool name.

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 output schema and no annotations, so the description is the only source of behavior. Yet it omits the meaning of the single sessionId parameter and any default-scope details. For a tool with a generic sibling like net_list, this is insufficient for confident, 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?

The only parameter, sessionId, is completely undocumented in the schema (0% coverage) and is not mentioned in the description. The description adds no meaning to this parameter, leaving an agent unable to determine whether it filters by browser session, is required, or what format it expects.

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 ('List') and a clear resource ('WebSocket connections'), with result contents summarized as frame counts and recent frames. It differentiates from generic network siblings like net_list by naming WebSockets explicitly, though it doesn't directly contrast itself with sibling tools.

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

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

No when-to-use guidance is provided. The description does not say when to choose net_ws over net_list, net_get, or other network tools, and it gives no exclusions, prerequisites, or context. The only implied usage is from the tool name and content summary.

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 key behaviors: steps settle briefly, one combined delta is reported, it stops on first failing step unless disabled, and the look option provides a final page_look. It also warns about ref invalidation, which is critical operational behavior. It doesn't mention potential side effects like navigation, but those are inherent to the actions.

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 long but every sentence earns its place: example, action list, behavioral notes, and options. It front-loads the core concept and example, then adds necessary details. For a tool this complex, the length is justified 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?

Given the tool's complexity (12 actions, multiple targeting methods, and options), the description is thorough. It covers usage, examples, edge cases (ref invalidation), error handling (stopOnError), and output (combined delta). No output schema exists, but the description states what the tool reports, so an agent has enough context to invoke it 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?

The schema already describes most parameters (71% coverage), but the description adds significant meaning: it explains the action object structure, gives a concrete example, clarifies ref lifetime, and describes the look option's purpose. It goes beyond a mere parameter list and helps the agent construct correct steps.

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: running a sequence of actions in one call, with a concrete example and a list of supported actions. It distinguishes itself from individual page_* tools by emphasizing speed ('far faster than one tool call per step'), making its purpose unmistakable.

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

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

It provides strong usage guidance: when to use it (batching steps for speed), how to target steps (selector, text, ref), and important caveats (ref invalidation after DOM changes). It implies individual tools are for single actions but doesn't explicitly state that exclusion. The stopOnError and look options are also explained.

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 clearly discloses the mutation (click) and the reported outcome (network/console/url delta). It does not mention potential side effects such as navigation, popups, or failure behavior, which keeps it at a moderate level of transparency.

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

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

The description is a single, information-dense sentence with no filler. The action and targeting modes are front-loaded, and the output effect is stated at the end.

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 parameters, no output schema, and no annotations, so the description must carry most operational context. It explains the output only vaguely ('delta'), leaves sessionId undocumented, and does not address parameter requirements or selection conflicts. This is not complete enough for reliable invocation in a large sibling-tool environment.

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

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

The description adds real meaning to 'ref' (must come from page_snapshot) and 'selector' (CSS selector), going beyond the bare schema. However, sessionId is left completely unexplained, and the description does not clarify whether ref and selector are mutually exclusive or what happens if neither is provided. With only 25% schema coverage, this is partial compensation.

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

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

The description states a specific verb ('Click'), a resource ('an element'), and two concrete targeting modes ('ref from page_snapshot, or CSS selector'). It also differentiates itself from coordinate-based siblings like page_click_at by specifying element targeting rather than screen coordinates.

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

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

Usage is implied: this tool is for clicking an element and observing the resulting network/console/URL changes. However, it never explicitly names alternatives such as page_click_at, page_hover, or page_tap_at, nor does it state conditions for when not to use it.

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

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

With no annotations provided, the description carries the full burden and does solid work: it states the failure condition for out-of-viewport coordinates, and it discloses the post-click report (network/console/url delta). It doesn't fully document every side effect or prerequisite, but the essential behavioral traits are covered.

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

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

Three sentences, no fluff, and the most important fact — coordinate space alignment with screenshots — is front-loaded. Every sentence earns its place and the structure makes the tool's mental model immediately clear.

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

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

For a 6-parameter tool with no output schema and no annotations, the description covers the critical context: coordinate system, failure mode, and return delta. It doesn't spell out coordinate origin or interaction with existing page state, but the required information to call the tool correctly is present.

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 33%, so the description must compensate. It does add crucial meaning for x and y by defining the coordinate space and its alignment with screenshots. However, button, sessionId, and the exact meaning of clicks/waitMs beyond the schema text receive little or no additional semantic help.

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 ('Click') and resource ('raw viewport coordinate in CSS px'), and clearly scopes the operation to coordinate-based clicking rather than DOM-targeted clicking. It distinguishes itself from sibling tools like page_click by explicitly stating 'No DOM target needed (canvas/WebGL)'.

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 makes the appropriate context clear: use this when you have raw pixel coordinates from page_screenshot or page_look, and when no DOM target exists. It does not explicitly name an alternative for DOM-based clicks, though the 'No DOM target needed' phrasing implies page_click would be the 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?

With no annotations, the description carries the full behavioral burden. It discloses the exact event sequence (mousedown → move → mouseup), the coordinate system, the fact that no DOM target is required, and that it reports the resulting network/console/url delta, making side effects visible.

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 dense sentence where every clause earns its place: coordinate space, units, image-space equivalence, event sequence, no-DOM-target usage, and reported output. It is front-loaded with the action and contains 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?

The required parameters are semantically covered, the event behavior is explicit, and the reported delta is stated even without an output schema. The only notable gaps are the undocumented optional sessionId and the lack of detail about the exact shape of the reported delta.

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

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

Schema description coverage is only 17%, but the description compensates for the four coordinate parameters by defining them as raw viewport CSS-px coordinates in screenshot space. waitMs is already described in the schema, while sessionId remains unexplained, preventing a 5.

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 ('drag'), a precise resource (mouse at raw viewport coordinates), and a clear outcome (report network/console/url delta). It also distinguishes itself from coordinate-based siblings like page_click_at and page_tap_at by specifying mousedown→move→mouseup and no DOM target.

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

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

It clearly implies when to use this tool: when a drag gesture is needed in the same coordinate space as page_screenshot/page_look images and no DOM element is targeted. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries full responsibility. It discloses timeout behavior (stopped after timeoutMs), that a busy loop is terminated, and that a never-settling promise is abandoned. It also states the return type is the value directly. It doesn't mention error handling (e.g., what happens if the expression throws), but the disclosed behavior is meaningful and not contradicted by any annotations.

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 core purpose, then usage guidance, then behavioral constraints. Every sentence earns its place with zero redundancy. Highly efficient.

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

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

For a simple eval tool with no output schema, the description covers the essential points: what it does, when to use it, the return type, and timeout behavior. It doesn't explicitly explain sessionId or error handling, but given the tool's simplicity and the clarity of the rest, it is quite complete. The mention of page_observe as an alternative further rounds out the context.

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

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

Schema description coverage is only 33% (only timeoutMs has a description), so the description must compensate. It explains the expression via example ('document.title') and clarifies the timeout behavior and default (15000ms). However, sessionId is not explained at all, and the timeoutMs description in the schema already covers the default and max, so the description adds little new for that parameter. Partial compensation for the gap but not complete.

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

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

States a specific verb (evaluate) with a clear resource (JS expression in the page) and the result (return value directly). It explicitly distinguishes itself from page_observe by noting the absence of network/console side-effects, making it easy for an agent to pick the right tool among many 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?

Provides explicit when-to-use guidance ('quick, standalone read') and names the alternative tool (page_observe with {action:{kind:'eval'}}) for when side-effects are desired. This directly addresses the key usage decision for an agent.

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

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

With no annotations, the description carries the full burden. It openly discloses that the tool clears fields, fills them, and reports the network/console/url delta it caused, making side effects predictable. It could add waiting/settle behavior or session requirements, but the core behavior is not hidden.

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?

One dense, front-loaded sentence with no filler. Every clause contributes an operational detail: clearing, filling, targeting, batching, and the resulting delta report.

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 moderate-complexity tool with no output schema and no annotations, the description conveys the action, targeting mechanism, and what kind of result to expect (network/console/url delta). It could elaborate on session lifecycle and wait behavior, but the essential calling context is present.

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 33%, and the description adds useful meaning beyond the schema by explaining that ref values come from page_snapshot and selector values are CSS selectors. However, sessionId and the exact meaning of value are left mostly to inference, so the description only partially compensates for the coverage gap.

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

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

States a specific verb and resource: clear and fill multiple form fields in one call. It also identifies targeting modes (ref from page_snapshot or CSS selector) and the reported network/console/url delta, which distinguishes it from single-field siblings like page_type.

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 bulk form filling by saying 'multiple form fields ... in one call,' but it does not explicitly name alternatives, exclusions, or when to prefer page_fill over page_type/page_select. The usage context is clear but largely left 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?

With no annotations provided, the description carries the full burden and does substantial work: it discloses stable ref generation, invalidation of prior refs, AND semantics across criteria, interactive-only default behavior, and the opt-in for non-interactive elements. It also notes the selector-based escape hatch and how refs are consumed by later tools.

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 every sentence contributes: operation, return contract, differentiation, criterion constraints, default behavior, and invalidation side effect. It is front-loaded with the core purpose and avoids 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?

Despite having no annotations and no output schema, the description is complete enough for correct invocation: it covers what the tool returns, how refs are used, the input constraints, default scope, and the important side effect that prior refs are invalidated. Operational details like limit defaults and case-insensitivity are already in the schema.

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 already documents most parameters. The description adds meaningful relationship semantics: text/role/selector AND together, at least one is required, includeNonInteractive is appropriate for non-interactive targets. It does not clarify sessionId, but that seems like a standard cross-tool parameter.

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

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

The description names a specific verb and resource ('Find elements on the page') and clearly distinguishes the tool from page_snapshot as the targeted alternative. It also states the return concept (stable refs) and how the tool fits with sibling actions like page_click/page_type.

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

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

It explicitly calls out page_snapshot as the full-listing alternative and says this is the targeted choice. It gives the key usage constraint (supply at least one of text/role/selector) and explains when includeNonInteractive is appropriate, though it does not enumerate all sibling alternatives or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not explain side effects, whether it waits for page load, error handling, or what happens after navigation. This is insufficient for an agent to anticipate the tool's behavior accurately.

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

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

The description is a single, concise sentence with no unnecessary words. It front-loads the action and includes relevant session context. It is appropriately sized, though it could be expanded without losing conciseness.

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

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

For a navigation tool with two parameters and no output schema, the description is too sparse. It lacks information about return values, errors, session handling specifics, and whether navigation is synchronous or asynchronous. An agent needs more context to use the tool correctly and interpret results.

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

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

The schema has 0% description coverage, and the description does not mention the parameters 'url' or 'sessionId' at all. It fails to explain their purpose, format, or constraints beyond the schema's type hints. This is a critical gap for a tool with two 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 clearly states the action (navigate), the target resource (session), and the destination (URL). It is specific enough to distinguish from sibling tools like page_click or page_type, which perform different interactions. The phrase 'active (or given) session' adds context about session targeting.

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. It does not mention any prerequisites, conditions, or exclusions, such as when to use page_snapshot or page_read instead. An agent would have to infer usage from the tool name alone.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It does reveal meaningful behavior: the hover triggers a network/console/url delta report and accepts either a ref or selector. Yet it does not clarify prerequisites such as element visibility, whether the hover is synthesized, what happens on failure, or how deltas are returned.

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 with no filler. The verb and target are front-loaded, and the parameter clarifications are packed compactly into the parenthetical. Every part of the 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 conveys the core purpose and output dimensions, which is adequate for a relatively simple tool. However, with no output schema, no annotations, and only 25% schema description coverage, an agent is left guessing about how the delta is reported, whether a ref or selector is required, and what happens when multiple or no locators are provided.

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 25%, so the description must compensate. It adds meaning for ref and selector by explaining that ref comes from page_snapshot and selector is a CSS selector, but sessionId remains undocumented and the relationship/precedence between ref and selector is not addressed.

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 ('Hover'), identifies the resource ('an element'), and specifies the two accepted input forms ('ref from page_snapshot, or CSS selector'). It also names the output ('network/console/url delta'), which clearly distinguishes it from siblings like page_click or page_find.

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 makes the core use case clear: hover an element and observe resulting deltas. However, it does not explicitly state when to choose this over sibling tools such as page_click or page_find, nor does it provide exclusion criteria or alternatives.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose that the tool performs an actual key press and reports network/console/url changes, which is useful. However, it does not mention potential side effects like form submission, navigation, destructive shortcuts, session context, or the shape of the returned delta.

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 that front-loads the key action and the reported delta. It includes concrete examples and contains 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?

For a tool with three parameters, no output schema, and no annotations, the description leaves significant gaps: the returned delta structure, valid key encodings, session behavior, and side effects are not explained. It is minimally usable but not complete enough for reliable invocation in varied contexts.

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

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

The schema only describes waitMs; keys and sessionId are undocumented. The description gives examples of keys but does not explain the full supported key syntax, modifier formatting, or sessionId purpose. With schema description coverage at 33%, the description does not fully compensate for the gap.

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

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

The description states a clear imperative action, 'Press a key or key combo', identifies examples like 'Enter' and 'Control+A', and specifies the output as 'network/console/url delta'. This distinguishes it from sibling tools like page_type and page_click, which handle text entry and mouse actions.

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

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

The description implies usage for keyboard shortcuts and observing resulting page deltas, but it does not explicitly state when to prefer page_key over alternatives such as page_type or page_fill. No exclusions or when-not-to-use guidance is provided.

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

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

With no annotations, the description carries full burden. It discloses that the overlay is removed after capture, refs from prior snapshots/finds are invalidated, only truly visible elements get badges (covered/clipped are skipped and counted), the image is 1:1 with CSS px, and filters/inclusion options alter marking. These are valuable 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 dense but efficient. It front-loads the core purpose, then covers usage, visibility caveat, pixel mapping, optional filters, and invalidation—each sentence adds unique value without repetition. No filler or redundant phrasing.

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 complex tool with 7 optional parameters and no output schema, the description covers the essential behaviors: how to obtain refs, the impact of filtering, invalidation of prior refs, and pixel accuracy. It omits explicit mention of whether the screenshot is viewport-only or full-page, but the 'way you'd click it' phrasing and pixel mapping imply viewport. Overall, adequate for safe 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 86% (six of seven params described). The description adds extra meaning: text/role/selector filters mimic page_find, includeNonInteractive is ignored when selector is given, limit is in ref order, and fullRes preserves native pixels. This goes beyond the schema's straightforward 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: it captures a screenshot with numbered badges on interactive elements (Set-of-Mark) and a legend mapping badge N to ref eN. This clearly differentiates it from siblings like page_screenshot (plain screenshot), page_find (locating elements), and page_snapshot (DOM snapshot) by emphasizing the clickable-ref mapping.

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

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

It explicitly tells the agent how to use it: read the picture, pick a number, then call page_click with the ref. It also contrasts with page_click_at for raw CSS-pixel clicks and references page_find for filtering. It does not list explicit when-not-to-use cases, but the usage flow is clear and actionable.

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

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

With no annotations present, the description carries the burden and does substantial work: it discloses that the tool executes exactly one action and then reports only a compact delta (url change, network requests, console entries). It does not cover error behavior, exact return serialization, or permissions, but the core behavioral contract is clear.

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 filler. The primary behavior and output are front-loaded, and the usage alternative is stated compactly in the second sentence.

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

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

Given there is no output schema, the description adequately summarizes what will be reported, but it leaves some context implicit: how sessionId selects a page, what the delta entries look like, and what the default settle time means. It is minimally sufficient but not fully complete for a tool with nested action objects and no output schema.

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 33%, and the description does not compensate. It names the action kinds (goto/reload/eval/wait) but does not explain the nested action object, the meaning of sessionId, or the waitMs default/semantics beyond what the schema already states.

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-resource pair ('Run one page action') and defines the compact delta output. It also distinguishes itself from raw navigate/eval calls by naming the side-effects it reports, so an agent can separate it from page_goto and page_eval.

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

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

It explicitly says to use this tool 'instead of a raw navigate/eval call' and gives the reason: seeing side-effects without extra tool calls. It does not enumerate when-not-to-use cases or map all sibling alternatives, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature (visible text), default selector behavior, and the case-insensitive filtering. It does not mention potential edge cases like empty results or timeout behavior, but for a read operation the provided transparency is strong.

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 no filler. The primary action is front-loaded, options are listed compactly, and the usage guidance is tucked at the end. Every 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?

For a read-only tool without an output schema, the description explains the return type (text lines), default scoping, and filtering. It could mention that only visible text is returned (already implied) and that maxChars truncates, but that is in the schema. It's adequately complete for an agent to invoke 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 description coverage is 75%, so the baseline is 3. The description adds meaningful semantics for 'query' (filters lines, case-insensitive) and 'selector' (defaults to main/article/body), beyond the schema's brief text. It doesn't explain sessionId, but that is a common parameter across the tool family. Overall it enhances understanding.

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

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

The description clearly states the action (read visible TEXT content), the resource (page), and the default scope (main/article/body). It explicitly distinguishes from page_find ('To locate a clickable element instead, use page_find'), making 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?

Explicitly states when to use the tool ('Use this to search/read page DATA — content, prices, table text, does the page mention X') and when not to ('To locate a clickable element instead, use page_find'), naming the alternative tool directly.

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

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

With no annotations provided, the description carries the full burden and meets it: it discloses coordinate-space mapping to click/tap/drag tools, document-relative fullPage behavior with scrollY conversion, native pixel behavior of fullRes, element crop plus origin, and the expense of image content. No annotation contradiction exists.

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 every sentence earns its place: core coordinate mapping first, then each option and its caveat, then the alternative tool and cost warning. No filler or repetition of schema text.

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 what an agent needs to call the tool correctly: what is captured, coordinate semantics for downstream actions, variant behavior, when not to use it, and a cheaper alternative. The only minor omission is a precise note on how the image is returned, which is not essential for 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 40%, so the description must compensate. It adds meaning beyond the schema for ref/selector (crop plus page origin), fullPage (document-relative and click-unsuitable), and fullRes (fine detail at native pixels). Only sessionId goes unmentioned, but it is a conventional session context parameter and not central to this tool's behavior.

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?

Opens with a specific verb and resource: 'Capture a PNG screenshot that is 1:1 with CSS pixels.' It then distinguishes the default viewport capture from fullPage, element, and fullRes variants, and explicitly contrasts with page_look for numbered click targets, so an agent can separate it from siblings.

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

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

Gives explicit selection guidance: the default viewport is for reading coordinates to feed into page_click_at/page_tap_at/page_drag; fullPage should not be used for clicking and page_look/page_find is preferred; use sparingly due to cost. This is concrete and decision-ready.

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 that the tool reports the network/console/url delta caused by the scroll and mentions a settle time (waitMs) before reporting. This goes beyond a simple action description, though it does not cover edge cases like scroll-triggered navigation or iframe 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 two concise sentences, front-loaded with the core action. It efficiently conveys the two modes, default values, and the reporting behavior without any redundant phrasing.

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 main functionality but omits details such as what happens if both ref and selector are provided (precedence) or if neither is given. It also does not mention potential interactions with page state or nested elements. Given the tool has 5 parameters and no output schema, these gaps leave some ambiguity for 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 only 40% (dy and waitMs have descriptions; ref, selector, sessionId do not). The description adds meaning by explaining that ref/selector trigger element scrolling and dy is the vertical pixel amount, and it clarifies the default for dy and waitMs. It does not explain sessionId, but that appears to be a common context parameter across sibling tools.

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 the page') and specifies two distinct modes: scrolling an element into view via ref/selector, or scrolling the window by dy pixels. This distinguishes it from sibling tools like page_goto (navigation) and page_find (search) 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 provides clear context on when to use each mode (element scroll vs window scroll) but does not explicitly mention alternatives or when-not-to-use scenarios. Since it is likely the only scroll tool among siblings, the implicit usage is clear, but it lacks explicit 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 provided, the description carries the burden of behavioral disclosure. It does reveal that selecting triggers a delta report and implies a settle time via waitMs, but it does not state whether the action is destructive, reversible, or may cause navigation, which is a notable gap for an interaction tool.

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

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

A single sentence that is front-loaded with the action and resource, and includes both the selection method and the reporting outcome. No filler or 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 an interaction tool with no output schema, the description adequately conveys the return (network/console/url delta) and the settle behavior via waitMs. It omits details about sessionId and error cases, but given the tool's straightforward purpose, it is reasonably complete.

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

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

Schema coverage is only 20% (waitMs only), so the description compensates by explaining ref and selector as alternative locators and clarifying that value is the option to select. However, sessionId is not explained, and the description does not detail the format of the delta report, leaving some parameters under-documented.

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 (select an option by value), the target resource (a <select> element), and how to locate it (by ref or CSS selector). It also notes the side effect of reporting the network/console/url delta, distinguishing it from sibling tools like page_click or page_fill.

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 select elements but does not explicitly contrast it with alternatives or state when not to use it. It mentions the mechanism for locating elements (ref or selector) but offers no exclusions or prerequisites, leaving some inference required.

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 behavioral burden, and it does disclose useful traits: the operation affects an existing session without relaunching, and hasTouch defaults to false so mouse clicks can drive the game. This gives the agent meaningful insight into side effects and input behavior, though it does not fully detail all page-state implications.

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

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

The description is compact and front-loaded: it states the core purpose first, then gives relevant parameter guidance. Every clause earns its place, with no filler or repetition.

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

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

While the main game-viewport use case is well covered, the tool has 7 parameters and no output schema or annotations. The description does not explain how to provide sessionId, when to use device presets versus explicit dimensions, or what deviceScaleFactor controls, leaving some invocation choices underspecified.

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 43%, and the description adds value for width/height via the concrete 390x844 example and explains hasTouch behavior. However, sessionId and deviceScaleFactor are left unexplained, so the description only partially compensates for the low 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 identifies the operation: resizing an existing session's viewport, and explicitly states it does so without relaunching. This distinguishes it from launch-oriented and navigation-oriented sibling tools like browser_launch and page_goto.

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

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

It provides practical guidance for the main use case: use portrait dimensions for canvas/WebGL games so click coordinates land correctly, and keep hasTouch:false unless the game specifically needs touch input. It could be stronger by naming alternative tools or explicit when-not-to-use conditions, but the guidance is clear and actionable.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly reveals the DOM side effect (adding data-bfa-ref attributes), the stability of refs, and the invalidation rule. It could add more detail on output/return behavior, but the core side effects are disclosed.

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

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

The description is three focused sentences: purpose, invalidation behavior, and alternative routing. It is front-loaded and every sentence earns its place with no redundant phrasing.

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 what the tool does, how refs are assigned and used, when to re-run, and how it differs from a sibling tool. With no output schema, an explicit description of the return format would be ideal, but the purpose and consumption model are reasonably inferable from the text.

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

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

The description adds no parameter-specific meaning. The limit parameter is only documented in the schema, and sessionId is entirely unexplained. Since schema description coverage is only 50%, the description does not compensate for the unmodeled parameter.

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

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

The description names a specific verb and resource: snapshot the page's interactive elements and assign stable refs. It clearly distinguishes itself from page_find, which is for locating a specific element rather than listing all.

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 states when to re-run the tool ('after any action that changes the DOM') and why prior refs are invalidated. It also names the alternative tool and the condition that selects it, so an agent knows which tool to 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 transparency burden. It clearly frames the operation as a read-only report and enumerates all reported fields, including the non-obvious active net_throttle emulation status. It doesn't detail output formatting or error behavior, but those are secondary for a getter.

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 compact sentence front-loads the verb and resource, then packs the field list efficiently. There is no filler, repetition, or unnecessary detail.

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

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

For a simple optional-parameter getter with no output schema, the description covers the returned information and the read-only nature well. The main gap is the undocumented sessionId, which is minor because the parameter is optional and its purpose is inferable from the 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 only parameter, sessionId, has no schema description (0% coverage) and is not mentioned in the tool description. The description adds no semantic value beyond the parameter name itself, leaving the agent to infer that sessionId identifies the target session.

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 (Report) and names the resource (current page state), then enumerates the exact fields included. This makes its function unmistakable and helps distinguish it from page_snapshot or page_read.

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

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

The description implies the use case: when the agent needs current page URL, title, readiness, viewport, or throttle status. However, it gives no explicit guidance on when to prefer this over related tools like page_snapshot or page_read, nor any exclusions.

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

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

No annotations are provided, so the description carries full burden. It discloses the dispatched event sequence, the coordinate space alignment with screenshots, and the delta reporting (network/console/url). It also mentions the waitMs default. It doesn't specify failure behavior if touch is not enabled, but the requirement is clearly stated, so it's nearly complete.

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

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

The description is long but every sentence earns its place: purpose, coordinate space, event dispatch, prerequisite and how to enable, and a usage hint. It's front-loaded with the core purpose and uses a compact structure. Slightly verbose but not wasteful.

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 moderately complex (4 params, 2 required, no output schema). The description covers the purpose, coordinate system, event behavior, prerequisites, and the return delta. Missing details include sessionId usage and exact return format, but these are minor given the thorough coverage of the critical aspects.

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 25% (only waitMs has a description). The description compensates for x and y by explaining they are in CSS px in the same space as screenshots, and for waitMs by giving the default. However, sessionId is not explained anywhere, and the description doesn't elaborate on coordinate ranges or units beyond the schema. Given the low coverage, it adds value but doesn't fully compensate.

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 (Tap) and resource (raw viewport coordinate) and immediately distinguishes it from the sibling page_click_at by stating it dispatches touchstart→touchend for touch-aware games. It also names the alternative explicitly in the closing sentence, making the purpose unmistakable.

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

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

It explicitly states when to use this tool: when a game ignores page_click_at, and gives the exact condition (touch emulation required) with two concrete ways to enable it (device:'mobile' or hasTouch:true via browser_launch/page_set_viewport). This is textbook usage guidance with a clear alternative and exclusion criteria.

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

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

With no annotations, the description carries the full burden. It discloses that the tool reports network/console/url deltas and explains the clear:true behavior. However, it does not mention potential side effects like navigation, the need for a loaded page, or whether typing waits for element visibility. The disclosure is adequate but not exhaustive.

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 no redundancy. The core purpose is front-loaded, followed by the unique delta-reporting trait and a practical note about clear. Every word earns its place, 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?

Given the tool's complexity (6 params, no output schema, no annotations), the description covers the main functionality and the unique reporting behavior but omits important context like the role of sessionId, whether it can trigger navigation, and how it interacts with page_snapshot refs. It is adequate for basic use but not fully comprehensive.

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

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

Schema description coverage is 33%, so the description must compensate. It does explain ref and selector (via 'by ref from page_snapshot, or CSS selector') and clear (via the clear:true note), adding meaning beyond the schema. However, sessionId is left unexplained, and waitMs is only covered by the schema. The description partially fills the gap but not fully.

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 (element), and the targeting methods (ref or CSS selector), and highlights the unique delta-reporting behavior. It clearly distinguishes the tool from simple typing tools like page_fill, though it doesn't explicitly name a sibling.

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 this tool (when you need to observe the side effects of typing), but it doesn't explicitly contrast with alternatives like page_fill or page_key, nor does it state when not to use it. The context of reporting network/console/url deltas is present, but no explicit routing guidance is given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure — and it largely delivers: it discloses the mechanism (set directly on the element, bypassing the OS picker), the input constraint (absolute paths readable by this process), and the post-action behavior (reports network/console/url delta). It does not cover failure modes (e.g., unmatched selector or non-file input), which keeps it below 5.

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, each earning its place: the core operation is front-loaded, the path constraint is stated baldly, and the return behavior is captured. No fluff and no restatement of schema content.

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

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

For a 5-parameter tool with no annotations and no output schema, the description covers the essentials an agent needs: what the tool does, how to target the element, the path requirement, and what the call returns. Remaining gaps are sessionId semantics and error behavior, which are secondary for correct invocation.

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

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

Schema description coverage is only 40%, and the description compensates for the two most ambiguous parameters: 'by ref from page_snapshot, or CSS selector' explains ref and selector, which have no schema descriptions, and it reinforces the files absolute-path requirement with 'readable by this process.' waitMs is already covered by the schema; only sessionId remains undocumented in both.

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 ('Attach file(s) to a file <input>') and adds the OS-picker analogy, making the operation unmistakable. This tool's upload/attach function is unique among the sibling set — no other page_* or net_* tool covers file attachment — so there is no ambiguity about when it applies.

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 OS-picker equivalence ('the equivalent of choosing files in the OS picker') is clear context for when to use this tool, and the targeting options ('by ref from page_snapshot, or CSS selector') guide how to invoke it. However, the description names no alternatives or when-not-to-use conditions, which keeps it from a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it reveals OR semantics, that it resolves as soon as one condition holds, and the nuanced networkIdle behavior (long-polls/streams older than 5s do not block). This goes beyond the schema and materially changes how an agent predicts 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?

Two sentences, front-loaded with the core purpose, condition list, and usage alternative; no filler. The detail about network idle blocks is placed inside the parameter-relevant phrase, so structure stays efficient.

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

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

For a six-parameter wait tool with no output schema and no annotations, this description covers trigger conditions, OR behavior, return timing, and usage guidance. It leaves sessionId undocumented and doesn't specify timeout failure behavior, but those are relatively minor gaps given the schema documents timeoutMs and session context is likely system-managed.

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

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

Schema coverage is high (83%), so the schema already documents most parameters; the description adds cross-parameter semantics by stating conditions OR together. It does not add new per-parameter detail beyond the schema, but the interaction semantics are valuable.

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

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

Description opens with a specific action and target ('Wait until the page reaches a condition instead of sleeping') and enumerates concrete conditions: selector, text, URL substring, network idle. It also distinguishes itself from fixed sleeps, making its role clear even among wait-related 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?

It explicitly tells the agent when to use it ('use this rather than fixed waits') and names an alternative ('or net_wait'). The OR-any-condition note clarifies call construction, and the condition list gives concrete triggers for choosing this tool over unrelated siblings.

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

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

With no annotations, the description carries the full transparency burden. It explains what is restored and where, but does not disclose the most important behavioral trait: whether existing cookies/storage in the target session are overwritten, merged, or rejected, nor what happens if no saved state exists for the given name.

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

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

The description is a single focused sentence with no filler and front-loads the primary verb and object. It is concise, though the brevity is a contributing factor to some missing behavioral/parameter detail.

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

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

For a state-mutating tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks the overwrite/merge semantics, error behavior for missing saved states, and any indication of what the restore call returns or whether it is destructive.

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

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

Schema coverage is 0%, so the description must compensate. It partially does by tying the operation to session_save ('previously saved') and referring to the target as 'active (or given) session', but it never explicitly maps `name` to the saved-state identifier or `sessionId` to the target session.

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 action ('Restore'), a specific resource set (cookies + localStorage/sessionStorage), and a defined source/target (saved via session_save into active or given session). This clearly distinguishes it from the sibling session_save tool.

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

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

States that it must be used with data 'previously saved with session_save' and may target the active or a given session, giving clear selection context. It does not explicitly list exclusion cases or alternative tools, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose what is saved (cookies, localStorage/sessionStorage), the target session, and the output location. However, it does not state whether an existing file is overwritten, what happens on failure, or whether saving has any side effects on the live session.

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, well-structured sentence packs in the action, the scope, the data captured, the destination, and the companion restore tool. There is no filler or redundant restating of the tool name.

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 two-parameter tool with no output schema and no annotations, the description is largely sufficient: it explains both parameters and the intended usage. The only meaningful gap is the omitted overwrite/failure behavior, which an agent might need for safe invocation, but it is not critical for a typical save operation.

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

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

The schema provides no descriptions for 'name' or 'sessionId' (0% coverage), but the description compensates: 'name' is clearly used in the file path, and 'active (or given) session' explains the optional sessionId semantics. This gives an agent the meaning it needs beyond bare parameter names.

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

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

States a specific verb ('Save'), a precise resource ('session's cookies + localStorage/sessionStorage'), and an exact destination ('~/.bfa/state/<name>.json'). It also clearly pairs with session_restore, which distinguishes it from the related sibling and from other browser/session tools.

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

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

The description signals the intended workflow ('for later restore with session_restore') and clarifies the active-or-given session choice. It does not explicitly list exclusions or alternatives, but the pairing with session_restore gives an agent enough context to decide when this tool is relevant.

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