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

Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds that the breakpoint is for future requests only, does not inspect past traffic, and requires subsequent steps. Also explains how the URL pattern ties to list_breakpoints and remove_breakpoint.

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?

Description is a single paragraph of about 100 words, front-loaded with purpose, then usage sequence, then relation to other tools. Every sentence contributes. Could be slightly more compact, but efficient overall.

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 existence of an output schema, return values are not needed in description. Covers what, when, how, and parameter details. Could explicitly mention that the breakpoint causes a pause on request, but context is fairly 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 has one parameter 'url' with description. Tool description adds context: case-sensitive, should be a narrow endpoint path from list_network_requests, retain exact string for removal. This goes beyond the schema description. With 100% schema coverage, baseline is 3, but added value justifies 4.

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: setting a URL-substring breakpoint for future XHR/Fetch to inspect runtime arguments, variables, or payloads. It distinguishes from get_request_initiator, which handles already captured requests.

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

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

Provides explicit guidance: use when need to inspect request details at runtime, avoid for already captured requests (use get_request_initiator instead). Specifies the workflow: set before reproducing action, then call get_paused_info/evaluate_script, then step/resume. Also notes it does not inspect past traffic.

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?

Despite destructiveHint=true annotation, description adds detail on what is irreversibly cleared (request queue, cached response bodies, initiator maps) and what is unchanged (cookies, HTTP cache, storage), exceeding annotation info.

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?

Concise paragraph with front-loaded action, followed by usage guidance, behavioral specifics, and contrast with sibling; every sentence adds value with no redundancy.

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

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

Given simple single-parameter tool with output schema, description fully covers purpose, usage, behavioral boundaries, and parameter semantics without missing critical 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 coverage is 100% for the single parameter 'confirm', and description reinforces its meaning as required for irreversible capture cleanup, adding nuance beyond 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?

Description uses specific verb 'discard' and resource 'captured HTTP(S) evidence', clearly distinguishing from sibling clear_site_data by stating what it does not affect.

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 ('immediately before reproducing an action when a clean network capture window is needed') and when not to use ('do not use it to reset login, cookies, cache'), with reference to alternative clear_site_data.

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 details what is cleared (cookies, persistent storage, sessionStorage) and what is not (page reload, HTTP cache by default), and explains the effect of clearBrowserCache. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with 'irreversibly clear'; no contradiction.

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 slightly verbose but front-loaded with the main purpose. Every sentence adds value, and the structure logically flows from purpose to usage to 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?

Given the presence of an output schema (context: 'Has output schema: true'), the description does not need to explain return values. It covers purpose, usage, parameters, and behavioral details comprehensively for a complex 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 coverage is 100%, but the description adds meaning by explaining that confirm=true is required for irreversible action and that clearBrowserCache has a global effect, providing context beyond the schema descriptions.

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

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

The description clearly states the tool irreversibly clears browser state for a clean replay environment, specifying the verb ('clear') and resource ('browser state for selected page'). It distinguishes from sibling tool 'list_network_requests' for cookie inspection.

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 use ('before replaying login, session creation...') and when not to use ('do not use it to inspect cookies'), and provides an alternative tool ('list_network_requests') for cookie provenance.

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

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description adds substantive context: the selector must resolve to exactly one element unless index is given, the element must be visible, confirm=true is required, and clicks can submit data or navigate. It also discloses that the result reports the exact resolved element. No contradiction with 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?

The description is front-loaded with purpose and then layered with usage, constraints, and safety context. It is slightly dense but every sentence contributes information an agent needs; no sentence is redundant filler.

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

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

The tool has an output schema, full annotation coverage, six parameters with 100% schema descriptions, and the description fills in the remaining behavioral gaps (uniqueness, visibility, confirmation, frame scoping). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic constraints beyond the schema: the one-element-match rule, the explicit visibility requirement, and the frame-selection prerequisite. It does not add new syntax details for modifiers or button, but those are already fully documented 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?

States a specific verb and resource ('Performs one verified, auditable click in the currently selected frame') and distinguishes the tool from evaluate_script and select_frame. An agent can tell exactly what this does and what it is not for.

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 names the conditions for use ('after selecting the correct page/frame and identifying a CSS selector'), the preferred alternative ('over arbitrary evaluate_script code'), and the when-not cases ('does not discover elements, type text, or silently guess among matches'). Nothing is 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?

Beyond the annotations, the description explains isolated-world versus mainWorld execution, that paused evaluation always targets the chosen call frame and ignores mainWorld, that frame/callFrameId expire after stepping or resuming, and that arbitrary code can mutate page or external state and requires confirm=true. It also discloses bounded inline results and the outputFile workaround for large or binary 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?

The description is dense and front-loads the core purpose, then adds usage, exclusions, runtime-mode caveats, and safety requirements. It is longer than typical, but nearly every sentence carries actionable information for a high-risk evaluation tool.

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

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

Given the dangerous, open-world nature of arbitrary code evaluation, the description covers intended use, prohibited use, execution contexts, paused-mode workflow, confirmation requirements, and large-result handling. With a rich input schema and output schema present, this is sufficiently complete 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 100%, so the schema already documents all seven parameters in detail. The description adds some useful cross-parameter context, such as paused mode ignoring mainWorld and using the selected call frame, but it largely repeats 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 uses a specific verb and resource: evaluating one focused JavaScript function for runtime values such as DOM state, web storage, globals, paused-frame expressions, or local-file processing. It clearly distinguishes the tool from sibling evidence tools by naming network-request and source-discovery 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 use conditions ('when those runtime values are the goal and no narrower evidence tool applies') and explicit exclusions for cookies and source discovery. It routes the agent to list_network_requests, search_in_sources, and get_script_source, and states when to call get_paused_info before paused evaluation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent with them. Beyond that it discloses non-obvious behavioral traits: returned frameIndex values and callFrameIds are valid only for the current pause and expire after any step or resume, which is exactly the kind of statefulness an agent cannot infer from annotations or schema.

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

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

Three sentences, front-loaded with what the tool returns, then the negative boundary, then the expiry caveat and next step. No sentence restates the name or repeats schema content verbatim.

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?

Output schema exists, so return shape needn't be explained; annotations cover the safety profile; schema covers all parameters. What remains for the description — pause state dependency, ephemeral handles, and the escape hatch to evaluate_script — is all 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 coverage is 100%, so all three parameters are documented in structured fields and the baseline is 3. The description adds real value by tying frameIndex to the pause lifecycle (expires on step/resume) and by pointing at evaluate_script as the consumer of that index; includeScopes and maxScopeDepth are left to the schema.

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

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

States a specific verb (inspects) plus three concrete resources (call stack, source locations, call-frame scopes) and the precondition that execution is already paused. It also explicitly negates the two adjacent capabilities (creating a pause, resuming), which separates it from pause_or_resume and step without the agent needing to inspect 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?

Gives the trigger condition (after a code/XHR breakpoint or explicit pause), the two things it does not do, and a concrete follow-on path: use evaluate_script with frameIndex for an expression, then step or pause_or_resume(action="resume"). Alternatives are named explicitly rather than implied.

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

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

Annotations already mark as read-only and non-destructive. Description adds key behavioral details: non-pausing, reads retained evidence, initiator capture is lazy and not retroactive. No contradiction.

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?

Single paragraph that is front-loaded with purpose and then flows into usage and alternatives. Every sentence is informative, though slightly dense; could be restructured but remains 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?

Given the tool's complexity and the presence of annotations and output schema, the description covers all contextual aspects: limitations, reproduction strategies, and references to sibling tools. 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 covers requestId fully with description. Tool description adds operational context: pass reqid from list_network_requests, notes on staleness and reproducibility. Provides value beyond 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?

Clearly states it retrieves the JavaScript initiator for a retained HTTP request, with a specific verb and resource. Distinguishes from siblings by mentioning alternatives like get_script_source, break_on_xhr.

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 (pass reqid from list_network_requests), when-not-to-use (older request may have no stack), and alternatives (reproduce, set break_on_xhr, use get_paused_info, evaluate_script).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it doesn't execute or pause the page, and discloses that scriptId is invalid after reload/navigation. This provides critical behavioral context beyond the 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?

The description is front-loaded with purpose and core guidance. It is slightly verbose but each sentence serves a distinct instructional purpose. Could be tightened, but remains efficient 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?

Despite 6 parameters and many sibling tools, the description covers selection strategies (URL vs scriptId), parameter combinations (line ranges vs offset/length), edge cases (scriptId invalidation, default length), and explicit alternatives (save_script_source, set_breakpoint_on_text). The output schema exists, so return values are not needed in the description.

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

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

Schema coverage is 100%, so the schema documents all 6 parameters. However, the description adds meaningful usage guidance: 'preferred stable selector' for url, 'ignored unless offset is provided' for length, 'for minified single-line code' for offset, 'inclusive 1-based' for lines, and invalidation conditions for scriptId. This enriches the schema without redundancy.

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 starts with a specific verb ('Reads') and resource ('small source region'), and immediately clarifies scope ('around a search match, paused location, or known statement') and what it does not do ('without executing or pausing the page'). It also distinguishes from sibling tools like save_script_source and set_breakpoint_on_text.

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 advises when to use URL vs scriptId ('prefer URL for external scripts'), when to use line ranges vs offset/length ('normal source' vs 'minified single-line bundles'), and provides alternatives for whole/minified/WASM source ('use save_script_source') and for runtime values ('call set_breakpoint_on_text'). Also explains when scriptId becomes invalid.

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?

Beyond readOnlyHint and destructiveHint annotations, the description discloses key behaviors: lazy capture start, non‑retroactivity, stable frame indices, monotonic but non‑zero starting indices, and eviction of old frames. This adds substantial value over annotations alone.

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 covering all modes and behaviours. While efficient, it could benefit from breaking into bullet points or sections for easier scanning. Still, it earns its place with no redundancy.

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

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

Given 10 parameters, multiple modes, and the existence of an output schema, the description is fully complete. It covers initialisation, pagination, filtering, analysis mode, frame indices, and preservation of connections across navigations. No gaps remain.

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%, but the description adds operational meaning: explaining mode combinations (e.g., without wsid lists connections, with wsid lists frames, with analyze=true groups frames). Clarifies that frameIndex is stable, not page‑relative, and that direction filters but does not apply in connection‑list mode.

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 inspects captured bidirectional WebSocket connections and frame payloads. It names the resource (WebSocket messages) and accurately contrasts with sibling tool list_network_requests for ordinary HTTP traffic.

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 (WebSocket, socket, live-update, etc.) and when not (use list_network_requests for HTTP/XHR/fetch). Details initialisation caveat (lazy capture, not retroactive) and mode switching between connection listing and frame inspection.

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

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

Annotations show readOnlyHint=true and destructiveHint=false. Description adds that URL-backed definitions may restore after navigation but IDs may change in rebuilt sessions, and that it returns breakpointIds and XHR patterns. No contradiction.

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?

Description is concise with three sentences, front-loaded with main purpose. No unnecessary words.

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

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

Has output schema, so return details are covered. Description provides enough behavioral context for breakpoint inspection and restoration, given tool 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 coverage is 100%, so baseline 3. Description does not add extra meaning beyond schema for pageIdx and pageSize 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 tool inspects code and XHR/Fetch breakpoints managed by the session. It uses specific verbs and resource, distinguishing itself from siblings like get_paused_info and remove_breakpoint.

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 tells when to use this tool: before reproducing an action or cleaning up debugger state. Also directs to use get_paused_info for active call stack, providing clear 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?

Beyond annotations (readOnlyHint, destructiveHint), description adds critical non-obvious behavior: capture starts on attachment and is not retroactive. No contradiction.

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?

Concise 4-sentence description with front-loaded purpose and alternatives, then clear parameter and behavior details. No unnecessary words.

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

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

Given 5 parameters, output schema, and sibling tools, the description covers all essential aspects: modes, filtering, pagination, capture timing. Complete enough for an 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 100%, so description adds value by explaining the dual modes (list vs single message), default page size, and optional filters. Slightly above baseline.

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

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

Clearly states the tool inspects console messages and uncaught page errors, with specific verb and resource. Differentiates from siblings by naming alternatives search_in_sources and list_network_requests.

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

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

Explicitly tells when to use (diagnose runtime failures, logs, etc.) and when not to (use other tools for source or network). Also describes modes and parameters affecting 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?

Annotations are readOnlyHint=false, destructiveHint=false. The description adds rich behavioral context: capture starts on attach, not retroactive, survives navigation with 5000-request FIFO, filter logic, default pagination, cookieName limitations. No contradictions. Provides details beyond 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?

The description is long but well-structured with front-loaded purpose. Every sentence adds value, covering many modes and details. However, it is dense and could be slightly streamlined for a quick read, but given the complexity, it remains 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?

Given 10 parameters, multiple modes, output schema exists, the description is exceptionally complete. It addresses capture behavior, filter logic, pagination, export options, cookie tracing details, and limitations. No significant 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 baseline is 3. The description adds extra meaning by explaining parameter interplay (e.g., cookieName + reqid flow, outputFile usage, pageSize default, filter AND/OR). Goes beyond schema by clarifying usage scenarios and combinations, but doesn't introduce entirely new 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 it inspects captured HTTP(S) traffic for the currently selected page, listing specific use cases like API calls, headers, auth flows, cookie tracing. It distinguishes from siblings by explicitly mentioning 'Use get_websocket_messages for WebSocket frame payloads; this tool only represents the HTTP upgrade request.' This provides a specific verb and resource, well differentiated.

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

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

Extensive usage guidance is provided: when to use cookieName vs reqid, when to export, default page sizes, AND/OR logic, non-retroactive capture, FIFO queue, and explicit alternative tool mention for WebSockets. Clear context for when and when not to use this tool.

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

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

Annotations already cover the read-only safety profile, and the description adds substantially beyond them: context scoping, inclusion of external/inline/eval scripts, and the crucial lifecycle fact that scriptId expires on reload, navigation, or target change. It also recommends URL as the preferred stable selector for downstream calls.

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?

Front-loaded with the core action, then alternatives, then result semantics. Dense and mostly waste-free, though the final sentence is long and packs several ideas (scriptId lifecycle, URL preference) that could be split for faster 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?

Output schema exists, yet the description still usefully summarizes what each result contains (context-scoped scriptId, external URL) and warns about expiry. Nothing needed to invoke correctly or to pick the right follow-up tool is missing.

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 schema already explains filter as a case-insensitive URL substring and the paging params. The description adds only indirect guidance about external vs inline/eval scripts, leaving the 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?

States a specific verb and resource ("Discovers JavaScript currently loaded in the selected debugger context") plus the default scope (main frame) and the exception (frame chosen with select_frame). Clearly separable from siblings like search_in_sources and get_script_source.

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 routing rules: call select_frame first for iframe-specific work, and use search_in_sources instead when a function name, endpoint, or code literal is already known. Both the when and the when-not are named with concrete triggers.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), but the description extensively discloses behavioral traits: it waits for DOMContentLoaded, invalidates old script IDs, restores breakpoints when possible, and does not clear cookies/storage/cache/site data. This adds significant value beyond the 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?

The description is well-structured and front-loaded with the main purpose. Every sentence adds necessary detail (contrast with sibling, behavioral notes, parameter guidance). There is no fluff, and the length is appropriate for the tool's 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?

Given the tool has 3 parameters, annotations, and an output schema, the description is remarkably complete. It covers when to use, behavioral implications, parameter relationships (e.g., omit type when url provided), and integrates with sibling tools. No gaps are apparent.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add new parameter-level information beyond what the schema provides (the schema already explains url, type, and timeout). The description's contextual use cases (e.g., reproduce requests, trigger breakpoints) are helpful but do not enhance parameter semantics specifically. Hence score remains at baseline 3.

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

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

The description clearly states the tool navigates, reloads, or moves through history in the currently selected page. It distinguishes itself from the sibling tool 'new_page' by specifying when a separate tab is required. The verb and resource are explicit.

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

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

The description explicitly provides guidance on when to use this tool versus 'new_page' (when a separate tab is needed). It also advises on when to call 'clear_site_data' for a clean replay, and how to handle breakpoints using 'get_paused_info' and 'pause_or_resume'. This gives clear context for appropriate 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?

The description goes beyond annotations (readOnlyHint: false, destructiveHint: false) by detailing behavioral traits: it waits for DOMContentLoaded (not every resource), makes the opened page the target for later tools, and preserves cookies/storage/cache. It also mentions using clear_site_data separately for a clean replay. No contradictions with 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?

The description is four sentences, well-structured: first sentence states the main action, second provides usage guidance, third adds behavioral details, fourth mentions state preservation. No redundant or unnecessary information; 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 the output schema exists and parameters are fully described in the schema, the description provides sufficient context: what the tool does, when to use it, behavioral characteristics, and contrast with sibling. It is 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 coverage is 100%, so baseline is 3. The description adds value by explaining the context of the url parameter (absolute URL, reusing about:blank tab), which is not fully captured in the schema's description. However, the timeout parameter is not elaborated beyond the schema, so not a perfect 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 clearly states that the tool opens a separate browser page for a URL, reusing an existing about:blank startup tab. It distinguishes itself from the sibling navigate_page by specifying that navigate_page changes the URL in the existing selected page, making the purpose specific and well-differentiated.

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

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

The description explicitly states when to use this tool (when the task needs another tab or should preserve the currently selected page) and when to use the alternative (navigate_page to change the URL in the existing selected page). This provides clear guidelines for tool selection.

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

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

Discloses state-changing behavior and invalidation side effect. While annotations are limited, description adds useful context beyond them. Could be improved by noting error scenarios.

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

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

Concise, front-loaded with main purpose, then alternatives and side effects. No redundant sentences.

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?

Complete for a simple tool: single parameter fully described, usage prerequisites, side effect noted. Given schema coverage and output schema presence, further detail unnecessary.

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 enum with descriptions; description adds valuable usage tips (when to use each value, ordering) that go beyond 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?

Clearly states it pauses or resumes execution explicitly, never toggles. Contrasts with break_on_xhr and step, providing clear purpose.

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

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

Explicitly describes when to use alternatives (break_on_xhr, get_paused_info) and warns that resuming invalidates callFrameId, offering clear 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?

The description discloses that removal does not resume a paused page, requires confirmation, and that breakpointId may need to be re-obtained after a debugger rebuild. This adds context beyond annotations (destructiveHint, idempotentHint, readOnlyHint) without contradiction.

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 that are front-loaded with the primary action and then provide usage specifics. No redundant or extraneous 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?

Given the tool has 4 parameters, 1 required, and an output schema, the description covers all essential aspects: removal modes, parameter usage, confirmation requirement, post-removal behavior, and edge case handling (breakpointId rebuild). 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?

Despite 100% schema coverage, the description adds meaning to each parameter: explains url as an exact substring pattern, breakpointId caveat about session rebuild, confirm's authorization role, and action enum values. This enhances understanding beyond the schema's brief 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 specifies the verb 'removes' and the resource 'breakpoint' with three distinct removal modes (code, XHR, all). It references sibling tools (set_breakpoint_on_text, break_on_xhr, list_breakpoints, pause_or_resume) to differentiate when each mode is applicable.

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?

Explicit guidance on when to use each action: use breakpointId from set_breakpoint_on_text/list_breakpoints for remove_code, use exact URL pattern from break_on_xhr/list_breakpoints for remove_xhr. Also clarifies that removal does not resume a paused page and suggests calling pause_or_resume separately.

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

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

The description discloses key behaviors: formatted line numbers may differ from live page, filePath is the resolved local path, and scriptId is scoped to current debugger context and becomes invalid after navigation/refresh. Annotations show readOnlyHint=false and destructiveHint=false, which are consistent. One minor gap: it doesn't mention that the saved file persists or any access restrictions beyond --allowedRoots.

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 detailed but every sentence is informative. It is front-loaded with the main purpose. While slightly long, it avoids redundancy. Could be trimmed slightly, but overall effective.

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 5 parameters with rich schema, output schema present, the description covers purpose, sibling differentiation, behavioral nuances, and parameter semantics. It mentions the returned filename implicitly. No obvious gaps 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 coverage is 100%, but the description adds significant context for each parameter. For url, it explains preferred source and matching strategy. format is described with clear use cases. filePath explains extension implications. scriptId clarifies scoping and invalidation. confirmOverwrite notes authorization. This goes well beyond the schema.

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

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

The description clearly states that the tool saves a complete JavaScript or WASM source for local inspection when an inline snippet is insufficient. It differentiates from siblings by mentioning 'Prefer get_script_source for a small known region and search_in_sources to locate text across loaded scripts first.' The specific verb 'saves' and resource 'source' make 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?

Explicit usage guidance is provided: prefer get_script_source for small regions, use search_in_sources first, and use set_breakpoint_on_text for debugging. It also clarifies when to set format=false and when to use confirmOverwrite. This helps the agent decide when to invoke this tool over its 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?

Annotations declare readOnlyHint and destructiveHint false, but the description adds important behavior beyond that: it searches without executing or pausing the page, covers external, inline/eval, and minified sources, and returns 1-based lines plus context-scoped scriptIds. It also notes that URLs are preferred selectors for URL-backed matches.

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 purpose is front-loaded in the first sentence, and the second sentence efficiently covers behavior, return shape, and alternatives. Although dense, every clause adds actionable information for selecting and invoking the tool.

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

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

The definition is complete for a search tool with seven well-described parameters, read-only annotations, and an output schema. It covers scope, alternatives, source types, and non-execution behavior without needing to restate return-value structure that the output schema already defines.

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 detailed parameter descriptions already carry most semantic weight. The main description adds some strategic guidance, such as preferring URLs for URL-backed matches, but does not explain the roles of maxResults, caseSensitive, maxLineLength, or excludeMinified beyond what the schema 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?

States a specific verb and resource: finding known function names, endpoints, literals, tokens, or code patterns in JavaScript sources loaded by the selected debugger context. It clearly scopes the search to the main frame by default or the frame chosen with select_frame, and distinguishes itself from sibling tools by naming 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?

Explicitly routes the agent: use select_frame for iframe-specific work, get_script_source for nearby context, save_script_source for whole bundles, set_breakpoint_on_text when runtime values are needed, and get_request_initiator for known captured requests. These are concrete when-to-use and when-to-use-alternative instructions.

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?

Discloses behavioral traits beyond annotations: omitting frameIdx lists without changing context; passing frameIdx changes target; indices shift after navigation or frame changes. No contradiction with readOnlyHint=false (mutates state) and destructiveHint=false.

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?

Single dense paragraph front-loads purpose, then usage, then behavior, then exclusions. Each sentence adds value; no fluff.

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 complexity (3 params, output schema), the description covers purpose, workflow, side effects, and exclusions. It references sibling tools for related actions.

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

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

Schema coverage is 100%, so baseline is 3. The description adds workflow context but does not significantly expand parameter meaning beyond what the schema 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 'Lists or selects frames, including iframes, within the current page.' It specifies the verb (lists or selects) and resource (frames within current page), and distinguishes from siblings like select_page and navigate_page.

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 tells when to use: 'when the target element... may live in an iframe' and provides a workflow: first list frames, then pass frameIdx before click_element or evaluate_script. Also tells when not to use: 'It does not switch browser tabs or navigate—use select_page or navigate_page for those actions.'

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 explains the behavioral nuance: listing does not change selection, passing pageIdx makes it the target. This adds value beyond the annotations, which only indicate non-destructive 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?

Three sentences, no fluff, front-loaded with the core purpose. Every sentence adds necessary detail without redundancy.

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

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

Given the complexity of selection and pagination, the description is complete. It covers all key behaviors and constraints, and an output schema exists so return values need not be detailed.

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% with good descriptions, but the tool description adds context about how each parameter affects behavior (e.g., pageIdx changes selection, listPageIdx only paginates). This 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 tool lists or selects open browser pages, with a specific verb and resource. It distinguishes from sibling tools like navigate_page and new_page by stating what it does not do.

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 tells when to use without pageIdx vs with pageIdx, and provides alternatives (navigate_page, new_page). It also clarifies that listPageIdx only paginates and never changes selection.

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

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

Adds context beyond annotations: restorable, returns breakpointId, limitation for inline/eval scripts.

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?

Dense single paragraph, front-loads purpose, but could be slightly more structured for 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?

Covers purpose, usage, workflow, return value, and limitations; output schema covers return details.

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?

Adds valuable guidance for each parameter (e.g., prefer confirmed snippet, condition restrictions, urlFilter source, occurrence usage).

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 it sets a URL-backed breakpoint on text, distinguishes from siblings like search_in_sources, break_on_xhr.

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 call directly vs. use alternatives (search_in_sources, break_on_xhr) and provides workflow after hit.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds critical behavioral details: invalidates prior callFrameIds, requires existing pause, and returns next call frame. No contradiction with 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?

Description is efficient and front-loaded with the main action. Three sentences cover behavior, prerequisites, and follow-up without fluff. Every sentence adds value.

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

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

Given full parameter schema, annotations, and output schema, the description is complete. It covers prerequisites, invalidation, and next steps, leaving no gaps for an 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 100% with descriptions for the direction parameter. The tool description does not add extra meaning beyond the schema, 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?

The description clearly states it advances JavaScript execution by one debugger operation from a pause, with a specific verb and resource. It distinguishes from siblings like pause_or_resume and get_paused_info by specifying its role in tracing control flow.

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 says to use after get_paused_info or evaluate_script when control flow needs tracing, and not from running execution. Also directs to use pause_or_resume to finish, providing clear context and 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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false); description adds critical behavioral details: default viewport vs. fullPage, oversized capture handling, filePath behavior and confirmOverwrite requirement, fully disclosing tool 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?

Concise 4-sentence description, front-loaded with purpose and usage, no repetition or fluff, efficiently communicates all necessary 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?

Given 5 optional parameters, full schema documentation, and presence of output schema, the description covers purpose, usage, behavioral nuances, and key parameter implications, making it fully self-contained.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds minimal param-specific insight beyond schema (e.g., fullPage behavior, oversized captures), but does not significantly enhance parameter 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?

Clearly states 'Captures the visual state of the currently selected page.' and distinguishes from sibling tools by specifying it is not a substitute for DOM values, network evidence, or script inspection.

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 lists use cases (verify page layout, UI state, etc.) and explicitly states when not to use it (not for DOM, network, or script), providing clear guidance for selection.

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