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

Beyond the destructiveHint annotation, the description discloses irreversibility ('Cannot be undone'), the replay-at-attach console behavior, the fact that cleared network requestIds may still resolve in get_network_response_body, and that clearing does not affect the DevTools UI. This is exactly the kind of behavioral detail an agent needs to avoid dangerous assumptions.

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?

Every sentence in the description earns its place: purpose, scope, irreversibility, edge-case behavior, and operational requirements. It is dense but not padded, and the core purpose is front-loaded before the caveats.

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 destructive action with a single optional parameter, the description covers the effect, the scope, the irreversibility, the nuance about cleared network request bodies, and the no-tab requirement. Nothing an agent needs to safely invoke this 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?

The schema already documents the optional 'targets' array with a default of both console and network, so parameter semantics are clear from the schema. The description adds general context that buffers are server-side but does not further describe the targets parameter, so it adds no significant meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Discard the buffers this server holds' and ties it to get_console_logs / get_network_requests. It unambiguously distinguishes itself from clearing Chrome or the DevTools UI, so an agent knows exactly what this tool does and 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?

It explains the precise usage context: call this before a following get_console_logs / get_network_requests to start fresh, and notes that capture keeps running so no reconnect/reload is needed. It also states a key boundary — nothing in Chrome or the DevTools UI is cleared — and that it works without a connected tab, giving the agent clear conditions for when this tool is appropriate.

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

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

Annotations carry only a title, so the description bears the full disclosure burden and does it well: the paused-state requirement, the error-instead-of-fallback behavior, and the shape of the return value (class name plus first-level properties, `…` where Chrome truncated, human-readable rather than parseable). That last point is critical since no output schema exists.

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

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

Front-loaded with the core capability, then scope differentiation, then the hard precondition, then the return-format caveat. Every sentence carries information an agent needs; nothing is restated from the schema or title.

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

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

With no output schema, the description must explain returns and does so (preview-shaped, truncated, not machine-parseable). Preconditions, error behavior, and frame discovery are all covered, so an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so both parameters (expression, frameIndex) are already fully documented in the schema, including the wrap-a-function-in-an-IIFE note and the 0 = top frame convention. The description adds only the get_debugger_state pointer for frame indices, which the schema also contains. 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 ('Evaluate a JavaScript expression in the scope of a paused call frame') and immediately delimits scope against the sibling evaluate_js by naming what it can read that evaluate_js cannot (locals, closures, `this`). An agent can distinguish the two tools without opening either 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?

Explicit precondition ('Only works while execution is paused') with the failure mode spelled out (error, no silent fallback to global scope), plus a routing instruction to get_debugger_state for frame indices and an explicit contrast with evaluate_js. Both when-to-use and when-not-to-use are covered.

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?

Only a title annotation exists, so the description carries the behavioral burden and does so richly: serialization vs. preview for DOM nodes/Errors/Maps, top-level await semantics, returned-promise non-awaiting, and microtask timing. It stops short of noting any permissions/limits or error behavior when the expression throws, which keeps it from a 5.

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

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

Information is front-loaded — core behavior, then return-value caveats, then the async-timing gotcha, then sibling routing. It is long and sentence-dense with some em-dash nesting, but nearly every clause conveys a distinct operational caveat.

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?

No output schema exists, so the description must explain return values, and it does: real values when serialisable, class-name-plus-first-level previews otherwise, marked truncation. Combined with the async-timing and scope limitations, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and already notes functions are not called, so the baseline is 3. The description adds value by specifying the expression is evaluated in global scope with DevTools-console semantics, clarifying how the argument is interpreted beyond the schema's wording.

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 ('Evaluate a JavaScript expression in the page, in global scope') and immediately scopes it against related capabilities. It names evaluate_at_frame and get_inspected_element explicitly so an agent can distinguish it from siblings without opening a 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?

Gives explicit when-to-use/alternatives: use evaluate_at_frame for local/closure variables at a breakpoint, get_inspected_element for $0, and put `await Promise.resolve()` or make a second call when reading state after a click. The routing conditions are stated, not inferred.

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 readOnlyHint=true, the annotation covers the safety profile. The description adds the 'computed' qualifier, clarifying that it returns resolved styles rather than inline or default values, but does not disclose edge cases like missing elements or invalid property names.

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 fluff. Every word contributes to clarifying the tool's 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 simple read-only tool with two well-defined parameters and an output schema, the description is sufficient. It conveys the essential function, though it omits any mention of error behavior or handling of non-matching selectors, which would be useful but not critical.

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 applies. The description paraphrases the schema ('given properties' and 'element matched by selector') without adding additional semantic details such as return format or default behavior.

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

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

The description clearly states the tool retrieves computed CSS values for specified properties on a selector-matched element, using a specific verb and resource. It distinguishes from sibling tools like get_html or get_title by focusing on computed styles.

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

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

No guidance is provided on when to use this tool versus alternatives such as evaluate_js or get_inspected_element. The description simply states the operation without context on selection criteria or exclusions.

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

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

Annotations already establish readOnlyHint=true, so the safety bar is lower, yet the description adds substantial behavior beyond it: source-mapped stack traces, a buffer that survives reloads/navigation with old entries preserved, an entry-level `from` marker for pre-document output, and the caveat that replayed entries carry no `timestamp` because Chrome supplies none. These are exactly the quirks an agent would otherwise misread as bugs.

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 purpose, then the buffer caveat, then the timestamp caveat — a sensible ordering with no filler. Slightly redundant with the existing output schema in its closing notes on `from` and `timestamp`, though those notes carry semantic value the schema alone may not convey.

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 three-parameter read tool with an output schema and readOnly annotations, this covers everything an agent needs: what is returned, that stack traces may be source-mapped, that the buffer is cumulative across navigations, and how to interpret entries that predate the current document. Nothing material 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%, including a detailed `since` enum doc that already explains the layered lower-bound semantics, so the baseline is 3. The description reinforces the pre-connect backlog concept but adds no parameter-level detail (no format, no interaction with `limit`/`level`) beyond what the schema already spells out.

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?

Specific verb ('Return') plus concrete resource ('browser console messages and uncaught exceptions'), with an explicit scope qualifier: it includes DevTools history that predates the server connection. That scope statement alone separates it from every sibling in the list, since no other tool surfaces console output or exceptions.

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 the semantics of the buffer thoroughly, but never states when to reach for this tool versus alternatives (e.g. get_debugger_state, evaluate_js, get_network_requests) or what a good reason to call it is. Guidance is implied by the note about navigating not clearing the buffer, but no explicit when-to-use or when-not-to-use is given.

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

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

With readOnlyHint already declaring the safety profile, the description adds substantial non-obvious behavior: pauses are reported regardless of cause, hitBreakpoints only reflects breakpoints set through this server and is therefore empty at DevTools breakpoints, positions are 1-based, and source-mapped frames expose compiledUrl/compiledLine/compiledColumn. These are exactly the traps an agent would otherwise misread as 'no breakpoint hit'.

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

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

Five tight sentences, front-loaded with the returned data before the caveats. Every sentence carries distinct information — content, reporting guarantee, breakpoint-source caveat, coordinate convention, source-map extras — with no restatement of the name or title.

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

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

An output schema exists, so return-value shape need not be spelled out here, and the description still pre-explains the trickiest fields. The one gap is environmental: it never states prerequisites (e.g., that a tab must be inspected/attached) for the state to be meaningful.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline for a no-parameter tool is 4; the description does not need to add more.

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?

Specific verb plus resource ('Get the debugger state') immediately followed by an enumeration of exactly what is included: paused status, pause reason, hit breakpoints, full call stack. This clearly separates it from siblings such as list_breakpoints (breakpoint inventory) and get_scope_variables (frame variables).

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: the agent must infer this is the tool to call when it needs to know if/where execution is paused. There is no explicit routing statement such as 'call before step_over/evaluate_at_frame' or guidance on when to prefer list_breakpoints or get_scope_variables. The 'hitBreakpoints' caveat is a data caveat rather than a when-to-use rule.

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 readOnlyHint annotation, the description discloses the exact 20000-character truncation behavior, the truncation marker format, and how 'short result' ambiguity is resolved. This is exactly the kind of behavioral detail an agent needs to interpret output correctly.

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 efficient sentences: the first states the action and scope, the second covers the only significant edge case (truncation) and its marker. No filler or redundant schema repetition.

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

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

For a no-parameter read-only tool with no output schema, the description provides the complete contract: source retrieval method, size limit, truncation indicator, and ambiguity resolution. Nothing needed to invoke or interpret this 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?

There are zero parameters, so there is nothing to document beyond the already-vacuous schema coverage. The description instead spends its text on return behavior, which is appropriate for a no-input tool.

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

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

The description opens with a specific verb and resource: 'Get the full HTML source of the currently connected tab'. It also specifies the exact implementation via `document.documentElement.outerHTML`, which clearly distinguishes it from siblings like get_title, get_url, and get_computed_style.

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 intended use case is clear from the stated resource and output: call this when the full page HTML is needed. It does not explicitly name alternatives or exclusion cases, so it falls just short of full routing 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?

readOnlyHint=true already covers the safety profile, and the description adds real behavioral context beyond that: the prerequisite that an element must be marked first, and the explicit failure mode ('Returns an error if no element is marked'). Not a contradiction — it is a read that depends on prior DevTools console 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?

Three short sentences: what it does, how to satisfy the precondition, and what happens on failure — front-loaded and with no wasted text. The ordering puts the purpose before the setup detail, which is the right priority for an agent scanning tools.

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

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

With zero parameters, an output schema already covering the return shape, and readOnlyHint annotations, the only remaining gaps would be preconditions and failure modes — both of which the description supplies. Nothing an agent needs to invoke this 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description usefully clarifies that the 'input' is external DevTools state ($0) rather than a tool argument, which prevents the agent from hunting for a missing parameter.

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

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

States a specific verb and resource ('Get the element marked for MCP inspection') and makes the scope distinct from siblings like get_html and get_computed_style, which read arbitrary page state rather than a user-marked element. An agent can tell immediately what this returns 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?

Gives an explicit prerequisite workflow ('select it in the Elements panel, then run `window.$0 = $0` in the DevTools console'), which is exactly the context an agent needs to advise a user on setup. It does not, however, name an alternative for the case where no element is marked (e.g. get_html), so the when-not path is only implied by the error statement.

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?

Read-only is already covered by annotations, yet the description adds substantial extra context: capture-start timing, pruning on navigation with the new document request retained, one record per redirect hop keyed by requestId/hop, WebSocket frames excluded, and what `canceled` versus `failed` mean. That is exactly the kind of non-obvious behavior an agent cannot infer from readOnlyHint.

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 return payload, then each subsequent sentence carries a distinct behavioral fact with no filler. It is dense — several independent caveats are packed into one paragraph — which costs some scannability but not correctness.

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?

An output schema exists so return values needn't be explained, yet field semantics (`size`, `canceled`, `hop`, truncated URLs) are covered anyway, along with capture-window limits and pruning rules. Nothing an agent needs to call this correctly or interpret results 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 real meaning on top: it explains the bulk-listing truncation behavior tied to `limit`, tells the agent to pair requestId with headerKeys for full detail, and clarifies that returned `size` is compressed on-the-wire bytes rather than a decoded length. It stops short of covering the status/resourceType filter trade-offs.

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

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

Opens with a specific verb+resource ('Return HTTP requests captured from the connected tab') and enumerates exactly which fields come back (method, URL, status, size, duration, initiator, failure reason). It also names a sibling (get_console_logs) to contrast scope, so an agent can distinguish it 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?

Gives clear operational guidance: capture only starts at connect time, pre-connect history is unavailable (explicitly contrasted with get_console_logs), and truncated URLs must be re-queried by requestId. It does not state exclusions among the network siblings (e.g., when to use get_network_response_body instead), so it falls short of a full when/when-not/alternatives treatment.

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 far beyond the readOnlyHint annotation, disclosing buffering behavior, navigation-related loss, redirect-chain semantics, return format, truncation at 50000 characters, handling of binary bodies, and the `note` replacement mechanism. This is rich behavioral context that an agent cannot infer from the schema or 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 every sentence carries distinct, high-value information: purpose, timing caveats, redirect behavior, return structure, metadata fields, error/omission cases. It is front-loaded with the core purpose and progresses logically through caveats and output details without waste.

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

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

With no output schema, the description fully explains what the agent will receive: a JSON metadata block, a separate text body, all metadata fields, the `note`/`truncated`/`omitted` variants, and binary-body behavior. Critical timing and lifecycle caveats are also covered, making the tool callable without further inference.

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

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

The schema only defines requestId as a string with 0% description coverage. The description compensates by explaining that the requestId comes from get_network_requests and represents a captured network request, which is the key meaning an agent needs. It does not detail format constraints, but the derivation from get_network_requests is sufficient for correct use.

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 opening sentence states a specific verb and resource: 'Fetch the response body for one requestId from get_network_requests.' This clearly distinguishes the tool from its sibling get_network_requests and other capture tools, so an agent can immediately know what it does.

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

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

The description gives strong timing guidance: fetch promptly and before navigating away because Chrome discards bodies. It also references get_network_requests as the source of requestIds. It does not explicitly enumerate when-not-to-use scenarios or name alternative tools, but the context is clear enough for correct routing.

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, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact — that it responds even when the page is unresponsive — which is exactly the kind of context annotations cannot carry.

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 sentences, front-loaded with what is returned, with the caveat about unresponsive pages appended. No filler.

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

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

A trivial no-arg read with annotations and an output schema, so almost nothing needs saying. The only minor omission is what happens if no tab is connected (error vs. empty result), which an agent might want to know before calling.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The stated return shape is a small bonus, though an output schema already exists.

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?

Specific verb and resource ("Get the URL and title of the currently connected tab") plus the exact return shape `{ url, title }`. It implicitly distinguishes itself from list_tabs/switch_tab by scoping to the already-connected tab, but never names those siblings 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?

Usage is only implied: the resilience note ("still answers while the page is not responding") hints at when it is preferable to evaluate_js or get_html, but the description never states when to use this instead of list_tabs or switch_tab, nor any preconditions.

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 readOnlyHint annotation, the description adds that the tool only functions while paused and that frame indices come from get_debugger_state, giving important operational context. 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?

Two concise sentences that front-load the purpose and include essential usage guidance without 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 readOnlyHint, complete parameter schema, and presence of an output schema, the description fully covers the tool's context, prerequisites, and usage, making it complete for an inspection tool.

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

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

The schema already covers both parameters with descriptions, but the description adds the crucial link between frameIndex and the debugger state, enhancing parameter semantics 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 uses the specific verb 'Inspect' with the resource 'variable values in a call frame scope,' clearly distinguishing it from debugger control tools like pause_execution or evaluate_at_frame.

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

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

It explicitly states a precondition ('Only works when execution is paused') and directs users to call get_debugger_state first to obtain frame indices, providing clear usage guidance and a sibling alternative.

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

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

Annotations already provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it only shows breakpoints created through this server, and explains the CDP limitation (no API to enumerate all breakpoints). This is valuable for setting expectations, though it does not detail the response format (which an output schema likely covers).

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

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

The description is two clear sentences, front-loaded with the action and scope, and adds a useful caveat without any wasted words.

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

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

With zero parameters and an output schema present, the description needs only to clarify the tool's scope and limitations, which it does thoroughly. The note about CDP's enumeration limitation is an important piece that makes the description 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?

The tool has zero parameters, so the description carries no parameter burden. A baseline of 4 is appropriate since there is nothing additional to explain.

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

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

The description clearly states the verb 'List' and the resource 'breakpoints tracked by this server', distinct from sibling tools like set_breakpoint/remove_breakpoint. It also differentiates by explicitly excluding breakpoints set via DevTools UI or other CDP clients, which removes ambiguity.

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

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

The description provides clear context: use this to list breakpoints set via set_breakpoint on this server. It implicitly warns against expecting externally-set breakpoints by stating they are not visible, which guides when not to use this tool. It does not name an alternative explicitly, but the context is sufficient.

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, so safety is covered. The description adds genuinely non-obvious behavior: `active` reflects on-screen visibility with the multi-window caveat, and the field is absent if the tab did not answer — an important signal about partial results that annotations cannot convey.

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 the core purpose, then the two ambiguous output fields. Every clause carries information; the nested em-dash aside about minimised/covered windows is slightly convoluted but resolves a real ambiguity.

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

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

For a zero-parameter read tool with an output schema and readOnlyHint, this covers what an agent needs: what is listed, what the two flag fields mean, and which tab is actionable. It leaves unstated only edge cases such as zero open tabs or whether all windows/profiles are included.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly does not waste space on inputs and instead spends its budget on output-field 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 and resource ('List open Chrome page tabs') plus the exact fields returned (targetIds, titles, URLs). It is immediately distinguishable from siblings like switch_tab or get_page_info, which act on a tab rather than 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?

Gives clear context: the `connected` field identifies the tab this server acts on and notes that only switch_tab changes it, which implicitly frames this as the discovery step before switching. It never states an explicit 'use this when' or an exclusion against get_page_info, so it stops short of a 5.

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

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

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses the 30s deadline, the full set of possible outcomes, that breakpoints carry over to the new page, and that a pause is terminated by the old page. This is exactly the behavioral context an agent needs before invoking a navigation.

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-loads the action and deadline, then enumerates outcomes compactly in one parenthetical. The outcome list makes the single sentence long and slightly dense, but no sentence is filler.

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

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

Despite a single-parameter schema, the tool has complex timing and pause interactions; the description covers those fully. An output schema exists, so the outcome enumeration is bonus clarity rather than a necessity.

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?

Only one parameter and schema coverage is 100%, with the schema already stating 'Absolute URL, including the scheme.' The description adds no additional URL syntax or constraint detail, so the baseline of 3 applies.

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

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

Specific verb and resource: 'Navigate the connected tab to a URL', with the added scope of waiting for the load event. It is clearly distinguishable from siblings like reload_tab and switch_tab, which do not take a URL or change the target document.

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 it can be called while paused ('no need to resume first'), which is the main usage trap for this tool. It does not, however, explicitly name when to use this versus reload_tab or switch_tab, so it falls short of full alternative routing.

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 only declare idempotent/non-destructive; the description supplies the real behavioral substance: a 2s window, what is returned (the call stack), and that a miss leaves the pause pending rather than failing. That pending-state semantics is exactly the kind of trait annotations cannot express and prevents the agent from retrying unnecessarily.

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. The primary behavior and the 2s return condition come first, and the idle-page caveat with the recovery path follows in the same breath.

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 no-parameter tool with no output schema, the description covers what happens, what comes back (call stack), the timing boundary, and the degenerate case. Nothing an agent needs to call it or interpret the result 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to add or omit. The description correctly spends no words on inputs and instead covers behavior.

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

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

States a specific verb (pause) and precise resource/scope (JavaScript execution at the next statement), plus the return value (the call stack). An agent can distinguish this from set_breakpoint or resume_execution without opening any schema.

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

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

Explains the crucial conditional case: on an idle page nothing runs, so the pause stays pending until a timer/event/click triggers script, and it routes the agent to get_debugger_state to check. It gives clear context but never explicitly contrasts with set_breakpoint (pause at a chosen line) or step_over, so sibling selection is still partly inferred.

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?

Goes well beyond the destructiveHint/openWorldHint annotations: discloses the 30s deadline, the three possible outcomes including the 'still-loading' edge case, breakpoint carryover to the new page, and that an active pause terminates with the old page. This is exactly the behavioral context an agent needs to interpret results.

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 action and the timeout, then the outcome enumeration. The middle sentence is dense but each clause carries real information; only mild tightening could improve it.

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 explains the outcome values and the paused-at-startup case, which is the key ambiguity for this tool. Nothing critical to correct invocation or result interpretation 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% and the single parameter ignoreCache is fully documented in-schema as Shift+F5. The description never mentions the parameter, so it adds nothing here — 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?

States a specific verb+resource ('Reload the connected tab') and immediately distinguishes itself from navigate/switch siblings by implying same-URL reload. The scope ('the connected tab') 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?

Gives clear context: use it after source changes, and explicitly says it 'also works while paused, no need to resume first'. No explicit exclusion versus navigate_tab, but the reload-vs-navigate distinction is implied clearly 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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds meaningful context: the ID becomes invalidated after removal and restoration produces a new ID. This informs the agent about side effects beyond the basic destructive flag, which is valuable behavioral disclosure.

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

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

The description is two sentences, front-loaded with the primary action, and every word adds value. It includes the key caveat (ID invalidation) and a hint about restoration without unnecessary elaboration.

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 destructive operation with one parameter and no output schema, the description covers the essential behavior, side effects, and an alternative. It does not mention error handling or return values, but these are not critical for such a focused tool given the siblings and annotations.

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

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

The schema provides only a required breakpointId string with no description (0% coverage). The description identifies it as 'a breakpoint by ID', linking the parameter to its role, but does not explain how to obtain the ID or its expected format. This is adequate but leaves some gap.

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

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

The description clearly states the action ('Remove a breakpoint') and the resource ('by ID'), making the tool's function unambiguous. It also distinguishes itself from sibling tools like set_breakpoint and list_breakpoints by focusing on removal and noting the restoration path.

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 practical guidance: it explicitly mentions using set_breakpoint to restore a removed breakpoint, which implies a clear alternative. It also notes the invalidation of the ID, helping the agent decide when this tool is appropriate. A brief mention of prerequisites (e.g., needing an existing breakpoint ID) would make it fully explicit.

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

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

Adds real value beyond the sparse annotations: it discloses that the call is non-blocking ('returns at once rather than waiting'), which is critical for an agent's control flow, and implies a paused-state prerequisite. It omits what happens if the debugger is not paused, and with only destructiveHint=true in annotations the description could say more about side effects of resuming.

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, no waste, with the core behavior (runs to next breakpoint) and the non-blocking contract front-loaded. 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 one-parameter tool with no output schema, the essentials are present, but the description never says what a resume returns (e.g. resulting debugger state or pause location) or how it fails when not paused. With thin annotations, a bit more behavioral context would complete the picture.

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

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

Schema coverage is 100% and the single 'terminate' parameter is documented richly in the schema itself (half-updated page, reload_tab remediation). The description adds nothing about parameters, 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?

Specific verb+resource ('Resume execution') plus the scope of the resume ('runs until the next breakpoint or pause'), which implicitly distinguishes it from the single-step siblings like step_over/step_into. It stops short of naming those siblings, so the differentiation must be inferred.

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?

'While paused' implies the precondition, so an agent can infer when the tool is applicable. However, it never states which sibling to use instead for single-stepping (step_over, step_into, step_out) or that pause_execution is the inverse, leaving the choice unguided.

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 readOnlyHint annotation, the description reveals important behaviors: captures only visible area, scaled/cut captures produce a note with CSS rect and pixel conversion, and non-painting tabs are raised to the front, changing tab selection. It also explains cost scaling with area. These details go well beyond what annotations provide, giving the agent a clear model of side effects.

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

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

The description is a single dense paragraph that front-loads the core function, then layers region and maxEdge guidance, and ends with the tab-raising side effect. Every sentence contributes value; it is efficient though slightly long. The structure is logical and easy to follow.

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

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

The description covers the capture scope, region behavior, maxEdge scaling, cost implications, side effects on tab selection, and even error conditions (off-screen region). With no output schema, it implicitly clarifies that a PNG is returned. 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% and both parameters have detailed descriptions in the schema. The tool description adds some usage guidance (e.g., 'Usually the right way to answer a question about exact pixels') but does not introduce new parameter semantics beyond the schema. This matches the baseline of 3 for fully documented parameters.

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

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

The description states a specific verb ('Capture'), a precise resource (the current viewport or a region of it), and explicitly excludes full-page, browser chrome, and DevTools. It clearly distinguishes this as the only visual capture tool among siblings, so an agent knows exactly what it does and what it does not.

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 strong context on when to use region vs the whole viewport, when to use native pixel size vs maxEdge, and even advises padding for alignment. However, it does not explicitly contrast with alternative tools (e.g., get_html or evaluate_js) for gathering visual information, though none of those are screenshots. The guidance is otherwise clear and actionable.

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

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

Annotations only supply idempotentHint, so the description carries the behavioral load and does so richly: pending binding when no script matches (`resolvedLocations` empty), binding on later load, and the crucial asymmetry that `source` breakpoints are dropped on file edit (surfaced under `droppedBreakpoints`) while `url`/`urlRegex` ones persist and may then stop on the wrong code.

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 action and coordinate base, then the targeting rules, then lifecycle caveats. Dense but purposeful; the source-map paragraph is long, though nearly every clause prevents a concrete failure mode.

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?

An output schema exists, so return values needn't be spelled out, and the description still explains the two return fields that change agent behavior (`resolvedLocations`, `droppedBreakpoints`). For a 6-parameter tool with subtle source-map semantics, nothing essential 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 real semantics beyond it: how `source` positions are remapped through source maps, why `url`/`urlRegex` positions are not, and the precedence/persistence consequences of choosing each. Conditional-expression behavior and column semantics are left entirely 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?

Opens with a specific verb+resource+coordinate system: "Set a breakpoint at a 1-based line (and column) of a file." It is clearly distinguishable from the list_breakpoints/remove_breakpoint siblings, which it never gets confused with.

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 between the three targeting modes: `source` maps through source maps into Chrome code, while `url`/`urlRegex` take positions exactly as Chrome loads them, with a warning that a source-mapped position given to them 'lands on the wrong line or never binds'. It also names the sibling that supplies the right coordinates (a frame's `compiledUrl`/`compiledLine`/`compiledColumn` from get_debugger_state).

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

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

The description discloses important non-obvious behavior beyond annotations: the step remains active after event handlers or timer callbacks, may pause in unrelated code, returns the new call stack, and times out after 5 seconds if execution does not pause. These details are critical for correct use.

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

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

The description is two dense sentences with the primary action front-loaded and no wasted wording. The added callback/timeout details are relevant and efficiently expressed.

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

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

With no output schema, the description provides the return behavior, timeout behavior, and the paused-state precondition. This is complete enough for an agent to invoke the tool correctly.

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

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

There are zero parameters, so there is no parameter semantics to explain. The baseline for a zero-parameter tool is 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 states a specific debugger action and distinguishes its behavior from a simple next-statement step by specifying that it steps into the called function when possible. An agent can understand exactly what the tool does relative to stepping generally.

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

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

The description clearly states the key precondition 'While paused' and explains the resulting behavior in edge cases. It does not explicitly name when to prefer step_over or step_out instead, so it lacks full sibling routing guidance.

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

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

Annotations only supply destructiveHint=false and a title, so the description carries most of the burden and does well: it discloses that execution actually resumes, what comes back (the new call stack), and the 5-second timeout fallback. It omits what happens if the tool is invoked when not paused, which is the main remaining gap.

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 the core semantics, then the edge case, then the return behavior. No sentence is padding — each adds a distinct operational fact.

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

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

For a zero-parameter debugger operation with no output schema, the description covers precondition, edge-case behavior, return content, and timeout — everything an agent needs to call it correctly and interpret the result.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and nothing about invocation is left unclear.

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 precise verb and mechanism: run the rest of the current function and pause in its caller. That uniquely identifies step-out semantics, but it never names the sibling alternatives (step_over, step_into, resume_execution) so an agent must infer the contrast from the definition 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?

The opening clause 'While paused' establishes the required debugger state, and the event-handler/timer caveat tells the agent what happens in the case where no caller exists. It stops short of explicit routing guidance — it never says to prefer step_over or step_into in particular situations.

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 adds substantial behavioral detail beyond the annotations: it explains that the step remains in effect after event handlers or timer callbacks, that execution may pause in unrelated code, and that it returns a new call stack or a 5-second timeout note.

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

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

The description is three focused sentences, front-loads the core stepping behavior, and every sentence contributes useful operational context without waste.

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

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

With no parameters and no output schema, the description is complete enough: it covers the paused prerequisite, the stepping behavior, the timeout behavior, and what the tool returns.

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

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

The tool takes zero parameters, so parameter semantics are not applicable; the baseline score of 4 is appropriate.

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

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

The description states a specific verb and operation: run the current statement without stepping into called functions, then pause at the next statement. It implicitly distinguishes itself from step_into by specifying that it does not enter function calls, though it does not explicitly name sibling tools such as step_into or step_out.

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 prerequisite 'While paused' gives clear context for when the tool is applicable, and the stepping semantics imply when to prefer it over step_into. However, there is no explicit when-not guidance or named alternative tool comparison.

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 carry only a title, so the description must do all the work, and it does: it discloses that breakpoints from the previous tab are removed, that an existing pause ends unless DevTools is attached, and that console/network buffers are cleared and refilled. These are exactly the destructive side effects an agent needs before re-targeting a debugger session.

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

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

Four short sentences, each carrying distinct information: the core action first, then the non-focusing property, then two concrete state-effects. No filler and the most important constraint is front-loaded.

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

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

An output schema exists and covers return values, and the side-effect profile is fully spelled out. The only gap is failure/edge behavior — what happens if targetId is stale or the tab is closed — which an agent would likely want before switching.

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

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

Schema coverage is 100% and the single parameter already documents itself as a target ID from list_tabs. The description says nothing about targetId, so it adds no meaning beyond the schema — baseline 3 under a fully documented 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 — connect the server to another Chrome tab — and adds a distinguishing scope note ('without bringing it to the front') that separates it from a plain tab activation. It implicitly contrasts with navigate_tab/reload_tab by framing itself as a re-targeting of the server rather than an action on page content, but 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?

Usage is implied: reach for this when you need to operate on a different tab. There is no explicit 'use this when X, not Y' and no prerequisite statement (e.g., that the target must already be open or obtainable via list_tabs) — that hint lives only in the schema. Adequate but inferential.

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