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

With no annotations, the description carries the full burden. It usefully discloses 'Read-only except cancel,' clarifying that three of four actions are non-mutating. However, it doesn't say what cancel does to stored results (destructive? reversible?), nor permissions or timing behavior for status polling.

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 sentence with the resource and provenance front-loaded and the read-only caveat at the end. No filler; 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 two-parameter tool with full schema coverage and no output schema, the description covers origin, actions, and mutation caveat adequately. Minor gap: no mention of how 'list' behaves (scope/pagination) or how long results are retained.

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

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

Schema coverage is 100%, so both jobId and the action enum are fully documented in the schema. The description adds no parameter meaning beyond the schema's own text, so baseline 3 applies.

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

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

States specific verbs (poll/cancel) and resource (background jobs) and names the exact origins of those jobs (media_extractor batch_extract, see_page steps, execute_js). An agent can distinguish this from siblings like wait or get_content without opening the schema.

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

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

Clearly scopes usage to jobs created with async:true on three named tools, which is a strong selection signal. It stops short of explicitly contrasting with the sibling 'wait' (i.e., when to poll vs. block) or stating 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 must carry behavioral transparency on its own. It does state the core behavior—closing the session and releasing resources—which is meaningful. However, it does not disclose potential side effects such as losing page state, pending actions becoming invalid, or the implications of force-killing beyond what the schema parameter description already says.

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, grammatically complete sentence that communicates the essential action and consequence without filler. It is appropriately sized for a simple one-parameter tool and front-loads the primary action clearly.

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, zero-required-parameter tool with no output schema, the description is mostly adequate, but it lacks usage context and side-effect warnings. The tool is destructive in nature, and an agent would benefit from knowing that closing the session is irreversible and that force is only needed when normal close fails. Overall completeness is acceptable but has 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 100%, so the 'force' parameter is already documented as 'Force-kill the browser process.' The description adds no extra meaning about when force should be true or what the default behavior implies. This meets the baseline for a fully schema-documented parameter but does not exceed 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 ('Close') and identifies the resource ('browser session'), making the tool's function unmistakable. It also clearly differentiates from siblings like browser_init and navigate by stating this terminates the entire session. No ambiguity remains about what operation this tool performs.

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 call this tool versus alternatives, such as using it only at the end of a browser session or not for closing individual tabs. Nothing distinguishes appropriate usage scenarios or warns against misuse. The only implied context is the tool's name and sibling relationships, which is not explicit 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, and it does disclose some behavior: automatic recovery of stale sessions, fingerprint spoofing, WebRTC leak protection, and resource filtering. However, it omits key lifecycle semantics an agent needs — whether a second call replaces or reuses an existing session, whether prior state is destroyed, and what a 'session' handle looks like.

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, no filler, and the core action is front-loaded before the option enumeration. The long comma-separated capability list is dense but each item maps to a real parameter, so little is wasted.

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

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

For a 10-parameter session-creation tool with no annotations and no output schema, the description covers the option surface but leaves lifecycle questions unanswered: what the call returns, whether sessions must be closed, and how repeated calls behave. It is adequate but not sufficient on its own.

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

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

Schema description coverage is 80%, so the schema already documents nearly all ten parameters, including the non-obvious ones (fingerprint, aiHealing, widgetAssist). The description's option list largely restates those parameter names and adds no format, default, or conflict-resolution detail beyond what the schema provides, making baseline 3 appropriate.

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

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

The description gives a specific verb and resource ('Initialize a browser session') and enumerates the capability areas (headless, proxy, viewport, video, filtering, spoofing, WebRTC). It never names or distinguishes itself from siblings such as browser_close or navigate, so sibling differentiation is absent, but the purpose itself is unambiguous.

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

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

There is no when-to-use guidance: no statement that this must be called before navigate/click/see_page, no condition for choosing it over an existing session, and no mention of pairing with browser_close. 'Automatically recovers stale sessions' is a behavioral trait, not usage routing, so an agent gets no help deciding when to invoke this.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses several capabilities (drag-and-drop, iframe context, hover, video player API, automatic retry with fallback selectors), but it does not mention side effects (navigation, form submission), permissions, or failure behavior beyond retry. This is useful but incomplete for a potentially destructive action like clicking.

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

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

Two sentences, front-loaded with the primary action and then a compact list of supported behaviors. No filler or redundancy; every sentence earns its place.

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

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

Given a rich schema (21 params, 90% coverage, nested object) and no output schema, the description covers the main capabilities adequately. It does not explain parameter interactions or the anyOf requirement, but the schema handles those details, so the description is nearly complete for its complementary role.

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 90%, so the schema already documents nearly all parameters in detail. The description only references dragTo, iframe, hover, and retry at a high level, adding no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Click or drag a page element by CSS selector or annotation ID.' It is immediately clear what the tool does and how the target is specified, distinguishing it from siblings like type or press_key without needing to enumerate them.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., type, press_key, execute_js) or when not to use it. The only implicit hint is 'use instead of selector' for annotationId, which is parameter-level, not tool-level.

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 does identify the tool as an inspection ('Inspect') that covers many read-oriented aspects of a page. However, it does not disclose whether the operation is truly read-only, whether it triggers network requests, how long it may take, or how results are returned. The listed coverage areas provide useful transparency, but side effects and output behavior remain unclear.

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 that front-loads the main purpose ('Inspect the current page in depth') before listing coverage areas. It is compact and free of filler, though the long enumerate list is slightly run-on and could be structured with separators or short phrases for easier scanning.

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 broad analysis tool with no output schema and no annotations, the description lists what is inspected but not what the agent should expect in return, whether results are aggregated, or how the optional boolean parameters alter the output. It is adequate for a first-order understanding but leaves operational detail unexplained.

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 67%, and the tool description adds no parameter-level meaning. The 'detailed' boolean is left undocumented, and the 'detectAccessControls' schema description ('Identify embedded widgets and page components') appears mismatched with the parameter name. The tool description echoes 'content-loading strategy recommendations' which maps to aiInsights, but that is redundant with the schema rather than additive.

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 ('Inspect') and a concrete resource ('the current page'), and then enumerates a distinctive set of inspection areas (DOM, scripts, stylesheets, accessibility, performance, SEO, response headers, technologies, loading strategies). This makes it clearly distinguishable from sibling tools like see_page or get_content, which are narrower content/visual viewers.

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 comprehensive, multi-faceted page analysis, but it does not explicitly state when to use it over siblings such as see_page, get_content, extract_data, or api_analyzer. There are no when-not-to-use conditions or alternative routing hints, leaving the agent to infer the intended use case.

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

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

With no annotations, the description carries the burden and does add real behavioral context: cookies/auth are inherited from the page session, fetch has a 30s timeout, and output is structured as status/headers/body. It omits the elevated trust level of arbitrary page-context code execution and what happens on script errors, but the fetch-mode semantics are unusually well 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 sentences with the primary capability front-loaded and the secondary mode clearly signposted by 'Also supports'. The middle clause is a compressed parameter summary that reads slightly like a teaser list, but nothing is wasted.

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

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

For a 12-parameter, no-annotation, no-output-schema tool this covers the two modes and the fetch return shape adequately. Gaps remain around what execute mode returns, error/timeout behavior beyond fetch, and the async job hand-off, which is left entirely to 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 92%, so parameter documentation is already largely handled and the baseline is 3. The description mirrors the schema's framing (async support, return value capture, iframe targeting, fetch action) rather than adding format or behavioral detail beyond it, and says nothing about the 200k code length cap or the timeout/returnValue interactions.

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

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

States a specific verb+resource combination ('Execute custom JavaScript in the page context') and enumerates the three capabilities (async, return value, iframe targeting) plus a second mode ('action="fetch"' for HTTP replay). Among siblings it is clearly the only arbitrary-code tool, though it doesn't explicitly name which sibling to use instead for read/extract tasks.

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 when-to-use / when-not-to guidance or named alternatives; the async path's hand-off to async_job polling appears only in the schema, not the description. Usage is implied by the capability list, so an agent must infer that this is the fallback when structured tools like get_content or extract_data can't do the job.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful scope information: extraction is from the current page, and links mode includes nested iframes. However, it does not disclose return behavior, auto-mode behavior, potential side effects, or whether any network/API calls are triggered by modes like apiDiscovery.

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 with the core action front-loaded and the mode list following. It is efficient and contains no filler, though the long comma-separated list is somewhat heavy and could benefit from clearer grouping or line breaks.

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 complex 14-parameter tool with no output schema and no annotations, so the description must compensate. It provides a useful mode inventory but does not explain mode-to-parameter mapping, default behavior, return values, or failure modes. An agent would likely need to inspect the schema carefully and still be uncertain about how modes like apiDiscovery or transform behave end-to-end.

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 at 86%, so the baseline is 3. The description adds value beyond the schema by defining ambiguous mode names: parse is 'string conversion,' transform is 'data format conversion,' and links mode explicitly covers nested iframes. This helps an agent understand the enumeration beyond raw parameter metadata.

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 and resource: 'Extract structured data from the current page,' and enumerates distinct extraction modes (regex, json, meta, structured, etc.). It does not explicitly differentiate from sibling tools like get_content or deep_analysis, but the mode list gives enough specificity that the purpose is not ambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives like get_content, api_analyzer, or media_extractor. It does not mention prerequisites, recommended modes for common scenarios, or exclusions. The only implicit usage signal is that it operates on the current page.

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 does add meaningful context: content can be returned in multiple formats, text/attributes/bounding boxes can be extracted, and results can be saved to a file. However, it does not disclose what is returned when saveAs is used, the effect of waitForJS, or whether rawHttp bypasses the browser rendering, leaving some behavioral gaps.

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

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

The description is only two sentences, front-loads the core purpose and format options, and avoids filler. Every sentence adds useful information about what the tool does or supports.

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 11 parameters, no annotations, and no output schema, the description is adequate but not complete. It explains the core operation and parameter-backed capabilities, but it does not describe the return contract, especially the behavior when saveAs is used, nor does it clarify how this tool relates to extract_data and see_page.

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 at 82%, so the baseline for this dimension is 3. The description adds a little extra meaning by mentioning bounding box coordinates and file saving, which map to format=elements and saveAs, but it does not meaningfully clarify undocumented params like timeout or format beyond what the schema already provides.

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

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

The description clearly states the verb 'Get' and the resource 'page content', then names the available formats (html, text, markdown, rawHttp, elements) and types of extraction (text, attributes, bounding box coordinates). It does not explicitly differentiate this from sibling tools like extract_data or see_page, so it falls just short of a 5.

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

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

No guidance is given about when to prefer get_content over nearby sibling tools such as extract_data, see_page, or navigate. The description implies format-based use cases, but there are no exclusions, prerequisites, or explicit alternative-selection cues.

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, yet it says nothing about state mutation (switch_iframe changes frame context, player_control alters playback), permissions, side effects, or how batch_extract behaves without the async flag. 'Including nested iframes' and 'via player API' are the only behavioral hints for a 6-action, 15-param tool.

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

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

Two sentences, front-loaded with the core purpose followed by a compact action enumeration. Dense but every clause adds information; only mild density cost from packing six actions into one sentence.

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

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

For a tool with six distinct action modes, 15 params and no annotations or output schema, the description covers the action menu but not per-action parameter applicability or what each action returns. It is enough to pick an action, but not enough to call the more complex modes (player_control, decode_url, batch_extract) confidently.

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

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

Schema coverage is 73%, so the schema documents most parameters (deep, async, types, selector, encodedData, etc.) and the baseline is 3. The description adds meaning by mapping actions to capabilities, but it does not clarify which parameters apply to which action, nor does it explain the undocumented enum values (quality, playerAction) or decoderKey/decoderIV 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?

States a specific verb+resource ('Extract and control media from the current page') and enumerates all six actions with what each does, so an agent can map intent to action. It does not explicitly differentiate from plausible siblings like extract_data or network_recorder, which keeps it from a 5.

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

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

The parenthetical glosses for each action (e.g. 'player_control (play/pause/seek/sources)', 'decode_url (inspect converted string and token formats)') imply when each sub-mode applies. However, there is no explicit when-to-use guidance versus siblings like extract_data or network_recorder, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It usefully mentions automatic retry, configurable wait conditions, timeout, and waitForChallenge auto-solving Cloudflare-style challenges, but it does not explicitly state side effects such as changing the active tab, closing tabs, or whether navigation requires browser initialization.

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 first states the core action and then summarizes supporting capabilities. There is no wasted prose, and the parenthetical tab actions add useful detail without disrupting readability.

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

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

For an 11-parameter browser automation tool with no output schema and no annotations, the description covers the main capabilities but omits return behavior, tab-index semantics, and prerequisites such as browser initialization. It is adequate alongside the detailed schema but not fully complete on its own.

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 82%, so the schema already documents most parameters. The description mentions several capabilities (wait conditions, timeout, retry, waitForChallenge), but it does not add substantial meaning beyond the schema's own parameter descriptions, consistent with the baseline 3 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 states a specific verb and resource ("Navigate to a URL") and enumerates tab-management actions ("list, switch, new tab, close tab"), making the tool's scope clear. It does not explicitly name sibling tools to distinguish itself from get_content, wait, or browser_close, so it falls short of a 5.

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

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

The description explains what the tool can do but gives no guidance on when to use it versus alternatives such as wait, get_content, browser_close, or solve_captcha. It does not state when-not to use navigation or how the tab actions should be selected in 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 behavioral burden. It mentions some behavior, such as blocking images/trackers to boost speed and mocking API responses, but does not disclose critical traits like whether clear/clear_routes destroy data, how start/stop recording persists, what capture scope applies, or what permissions are required.

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

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

The description is front-loaded with the core purpose and then lists actions in a single compact sentence. The action list is long but useful for selecting the correct action, though the run-on enumeration is slightly dense.

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 complex 14-action tool with no annotations and no output schema. The description lists action names but does not explain return formats, data retention, start/stop recording semantics, or what each get_* action returns, leaving significant gaps 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 75%, so the schema already documents several parameters such as limit, offset, patterns, and mock configuration. The description adds action-name context but does not explain key parameters like filter, captureXhrBody, or aiDetectStreams, so it neither fully compensates nor adds strong semantic detail.

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: 'Record, inspect, and control network activity.' It also enumerates the 14 supported actions, making the tool's scope clear. It does not explicitly distinguish itself from siblings such as media_extractor or redirect_tracer, so it falls short of a 5.

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

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

The action list implies when to use the tool for recording, inspecting, and controlling network activity, and notes specific uses like blocking URLs for speed. However, it gives no explicit when-to-use versus alternatives, no prerequisites, and no when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden yet discloses nothing about focus requirements, which element receives the key event, error behavior for invalid key names, or side effects. It only restates the configurable parameters rather than describing how the tool behaves.

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

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

A single front-loaded sentence with no filler or repetition. It is appropriately sized, though the space saved is space not used for the missing behavioral context.

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

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

For a simple four-parameter tool with fully documented schema and no output schema, the description covers the basic operation. However, with annotations absent, it should at least state that keys are sent to the currently focused element/session, which is the main thing an agent could get wrong.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema with examples and defaults. The description merely echoes 'modifier keys, repeat count, and keystroke delay' without adding format or interaction details, so the baseline 3 applies.

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

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

The description states a specific verb (press) and resource (keyboard keys) plus the configurable axes, which is clear. It does not distinguish itself from siblings like `type` or `click`, so an agent must infer that this is for discrete key presses rather than text entry.

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

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

There is no guidance on when to use this tool versus `type` (text entry) or `click`, nor any mention of prerequisites such as an initialized browser session or a focused element. The agent is left to infer all selection criteria.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the core action and the automatic lazy-load triggering side effect, but it does not describe iframe targeting, smart/random direction semantics, smoothness behavior, or other potential effects on page 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 front-loaded sentence with no redundant words. It efficiently conveys the core action and key configurable aspects.

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 utility with all-optional parameters, the description plus schema is mostly adequate. However, with no annotations and no output schema, the description leaves behavioral context like smart/random direction and iframe targeting to be inferred rather than explained.

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%, and the description mainly restates high-level concepts like direction, amount, and lazy-loading. It does not add meaning for underspecified parameters such as smooth or the direction enum values smart/random.

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 ('scroll the page') and names configurable behaviors: direction, amount, and lazy-load triggering. This makes the tool's function clear and distinguishes it from sibling interaction tools like click or press_key.

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 its use for scrolling and triggering lazy-loaded content, and the schema exposes iframe targeting, but it does not explicitly state when to use this tool over alternatives or when not to use it. An agent must 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, the description carries the behavioral disclosure burden and does name the redirect mechanisms it follows and the return data. However, the claim that the result includes headers is at odds with the schema's includeHeaders default false, and it does not clarify whether tracing performs a live browser navigation that could affect the current session 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?

Two sentences with no filler. The core action is front-loaded, and each clause adds useful information: which redirect mechanisms are tracked and what the tool returns.

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 and return summary are present, but because there is no output schema and no annotations, important context is missing: whether the path is a list of hop objects, how headers depend on includeHeaders, and whether the trace mutates the current browser page. The schema defaults help, but they do not fully compensate for these 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 coverage is only 57%, yet the description adds no parameter-specific guidance for the undocumented url, maxRedirects, or includeHeaders fields. The mention of returned headers conflicts with the includeHeaders default, and the redirect-type details do not explain how the followJS and followMeta booleans affect the output.

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 ('Trace the complete redirect chain'), the concrete resource (a URL), and the exact tracking scope (HTTP 301/302, JavaScript navigation, meta refresh). It also states the return value, which makes it easy to distinguish this tool from browser-navigation or network-capture siblings.

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

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

The behavior implies the use case: analyze why a URL ends up where it does. However, the description never explicitly says when to choose this tool over alternatives such as replay_request or network_recorder, nor does it mention any exclusions or 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 carries the full burden and does well: it discloses the return payload shape and the important non-obvious behavior that steps execute without intermediate re-capture. It leaves unmentioned the baseline save/compare, mutation watching, and the async job behavior, all of which remain schema-only.

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

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

Two short paragraphs; the first states what the tool is and returns, the second is a labeled workflow rule. Every sentence carries decision-relevant information and the recommended invocation flags are 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 19-parameter, zero-required browser-capture tool with no annotations and no output schema, the description covers the core loop an agent needs (capture once, batch actions, recapture only on real change). It omits any mention of the async job path, baseline comparison, or mutation watching, which are secondary but not negligible given async changes the call semantics entirely.

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 95%, so baseline is 3; the description earns above baseline by explaining the relationship the schema cannot — that 'steps' runs sequentially after the capture with no re-capture between steps, and that fullPage/annotate are the recommended starting flags. It does not touch the other 17 parameters, but the schema documents them 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?

States a specific verb and resource ('Capture a snapshot of the current page') and enumerates precisely what the snapshot contains: screenshot image, optional page text, interactive element map, iframe inventory. That composite output implicitly differentiates it from single-purpose siblings like get_content or click, though no sibling is named explicitly.

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

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

Explicitly prescribes a call pattern ('Call once with fullPage:true and annotate:true'), states the alternative workflow (run all planned actions as a steps array without re-capturing), and gives the exact condition for a repeat call ('only when the page genuinely changes — new navigation, modal, or dynamic content load'). This is as close to a rulebook as a description gets.

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, yet it never says this is a mutating operation that types into fields, may click refresh buttons, and can submit the form (the `submit` param defaults to false but can trigger navigation). It discloses nothing about required page state, failure behavior after `maxRetries`, or what is returned, all of which matter for a 19-parameter side-effecting tool.

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

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

Two tight sentences with the capability list front-loaded and no filler. It is arguably undersized rather than overly verbose for a tool this broad.

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 19-parameter tool with nested objects, no output schema, and no annotations, the description leaves key questions unanswered: what it returns (answer text, filled form, status), what happens when all retries fail, and whether the page must be pre-navigated. It is minimally viable but not sufficient on its own.

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 95%, so the baseline is 3; the description's mention of 'JavaScript-based challenge widgets, image text transcription, and intelligent form field mapping' loosely maps to the `type`, `lang`, and `aiMatch`/`formData` params but adds no new semantics like selector precedence or how `auto` detection resolves.

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 set: automate form completion and interactive widget verification, covering JS widgets, image text transcription, and field mapping. The verb+resource is clear, though the description never uses the term 'captcha' that the tool name and `captchaSelector` imply, and it does not differentiate from siblings such as `type`, `click`, or `extract_data`.

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 names intended contexts (QA, automated browsing workflows) which implies when to reach for it, but gives no explicit when-not-to-use and no mention of the alternative of driving forms manually via `type`/`click` or of prerequisites like an already-loaded page.

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

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

With no annotations, the description carries the full burden. It does disclose real behavior beyond the schema: encryption behavior via passphrase, and that autosave fires on every navigation. However it omits what clear_cookies destroys, whether save_session overwrites an existing file, and any permission or side-effect warnings for a mutation-capable 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?

One sentence of purpose followed by a compact, parallel action list. Front-loaded and no filler; every clause carries information an agent needs to pick an action.

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, yet the description says nothing about what cookies, indexeddb, or service_workers return, nor how errors surface when sessionPath is missing or passphrase is wrong. For a 4-parameter, unannotated tool with no return documentation, this is a meaningful gap.

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

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

Schema coverage is 75% and the description adds genuine value on top: it maps each enum value to its semantic meaning (e.g. save_session persists cookies & storage to file, load_session restores without re-logging). It is silent on the interaction of passphrase with load_session/autosave, but the parameter descriptions in the schema cover that adequately.

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

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

States a specific verb+resource ('Inspect and manage client-side storage & sessions') and then enumerates all 7 supported actions with brief glosses, so an agent knows exactly what capability surface exists. No sibling tool in the list touches cookies/IndexedDB/service workers, so the boundary is inherently clear from the wording alone.

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

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

Usage is only implied through the action glosses ('restore state from file without re-logging' hints at the load_session scenario). There is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no comparison to any alternative approach for state persistence.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions clearing and delay, but largely restates schema parameters and omits important behavioral context such as focus behavior, wait/heal behavior, and what happens if the target is not found.

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

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

A single front-loaded sentence with no wasted words. It states the core action first and then the notable configurable features.

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 rich schema covers most parameter details and there is no output schema, so the description is adequate for the core action. However, for a 10-parameter browser automation tool with no annotations, it leaves target-selection and side-effect context to 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 description coverage is 90%, so the schema already documents most parameters. The description highlights delay, clearing, and iframe support but does not add syntax or targeting guidance beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource: "Type text into an input field." It adds configurable behaviors, but does not explicitly distinguish itself from sibling tools such as press_key or click.

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 no explicit guidance on when to use this tool versus alternatives, nor when to prefer selector versus annotationId. Usage is only implied by the mention of typing into an input field.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether timeouts throw errors, what happens when a selector never appears, the default/max timeout behavior, or any side effects; it mostly restates the enum modes.

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 that lists the supported wait conditions with no wasted text. It is appropriately sized for the core purpose.

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

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

For a browser wait tool with no annotations, no output schema, and low parameter coverage, the description omits failure semantics, parameter coupling, and timeout behavior. An agent lacks enough information to call it correctly in 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 33%, and the description does not explain how the 'value' parameter should be interpreted for each wait type or what role 'timeout' plays relative to the default. 'value' and 'timeout' remain underdocumented across schema and description.

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

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

States a specific verb (wait) and four wait conditions (selector, navigation, networkidle, timeout), clearly distinguishing it from browser action siblings like click or navigate. It lacks explicit comparison to alternatives, so it falls short of a 5.

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

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

The phrase 'before continuing' implies when to use it, but there is no explicit guidance on choosing between wait types or when to avoid waiting. The usage context is present but left largely to inference.

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