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?

With no meaningful annotations (only a title), the description carries the full behavioral burden and does so well. It discloses error behavior when not paused, the preview-like return format, and the truncation marker ('…'), all of which are beyond what the input schema or annotations provide.

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?

Each of the four sentences adds distinct information: scope capability, paused requirement, return preview details, and how to get frame indices. No filler or redundancy, and the most important clause is front-loaded.

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

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

The description covers the tool's core behavior, constraints, return format, and required prerequisite tool, which is complete for an evaluation tool with no output schema. An agent can correctly decide when and how to invoke it without needing to infer anything crucial.

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 has 100% coverage with decent parameter descriptions. The tool description adds context for the expression parameter (evaluates in frame scope, reads locals/closure/this) but the frameIndex guidance is largely duplicated from the schema's own description. Still, the added scope context justifies a slight lift from the 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 starts with a specific verb and resource: 'Evaluate a JavaScript expression in the scope of a paused call frame'. It also distinguishes itself from the sibling evaluate_js by noting it cannot read frame-local variables, which makes the tool's purpose unambiguous, even compared to similar tools.

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

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

The description explicitly states the core precondition: 'Only works while execution is paused', and explains the failure mode if violated. It names the alternative (evaluate_js) and points to get_debugger_state for finding frame indices, giving clear when-to-use and prerequisite guidance with no ambiguity.

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 include a title with no behavioral hints, so the description fully bears the transparency burden. It discloses serialization behavior (real values vs. previews for DOM nodes, Errors, Maps, etc.), async semantics (top-level await works but returned promises are not awaited), microtask timing (state changes not visible immediately), and scope limitations at breakpoints. This is thorough and accurate, with no contradictions.

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 adds critical information—serialization, async, microtasks, breakpoint scope, and alternatives. It is well-structured with semicolons and clear transitions, front-loads the core purpose, and avoids redundancy. There is no fluff; each clause earns its place.

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

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

Given the tool's complexity (async, microtasks, serialization, breakpoint scope) and the absence of an output schema, the description covers all aspects an agent needs to invoke it correctly. It explains return value formats, timing behavior, scope limitations, and routes to siblings where appropriate. 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?

The schema has one parameter 'expression' with no description (coverage 0%). The description implicitly defines it through the entire tool purpose, repeatedly referring to 'expression' and its evaluation. While it doesn't explicitly state 'the expression parameter should be a JavaScript expression string', the context makes this obvious. For a single simple parameter, this is sufficient, but slightly more explicit wording could earn a 5.

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

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

The description clearly states the tool evaluates a JavaScript expression in the page's global scope with DevTools console semantics. It explicitly contrasts with siblings evaluate_at_frame (for local/closure variables) and get_inspected_element (for $0), making the purpose unambiguous and distinguishing it from similar tools.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: it names evaluate_at_frame for local/closure variables at breakpoints and get_inspected_element for the inspected element. It also gives practical usage tips about async behavior (use await Promise.resolve() between click and read) and microtask timing, so an agent knows exactly how to sequence calls correctly.

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 declare readOnlyHint=true, so the read-only nature is covered. The description adds meaningful behavioral context beyond that: it reports that messages from before the server connection are included and that exceptions include source-mapped stack traces when available. This enriches the agent's understanding of what to expect from the call.

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

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

The description is three sentences with zero redundancy. The primary purpose is front-loaded, followed by scope and behavior details. Every sentence earns its place, making it easy for an agent to parse quickly.

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

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

With an output schema present, the return format is already specified. The description covers the main behavioral aspects (inclusion of pre-existing messages, stack traces) and the parameters are well-documented in the schema. It could optionally mention that results are limited to most-recent entries, but that is already implied by the schema's 'limit' description, so no critical information 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%, with both parameters (level and limit) fully documented in the schema. The description adds no extra parameter-specific information, so it does not improve on the schema's baseline. A score of 3 is appropriate given the high coverage.

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

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

The description opens with a specific verb and resource ('Return browser console messages and uncaught exceptions'), clearly distinguishing it from network or debugger tools. It further specifies the scope (including pre-existing messages) and stack trace details, making the tool's function unambiguous even without reading 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?

The description explains what the tool returns and the inclusion of pre-existing messages, giving implicit context for when it is useful, but it never explicitly states when to use this tool over alternatives (e.g., get_network_requests) or when not to use it. No exclusions or comparisons are provided.

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

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

The readOnlyHint annotation already indicates a non-mutating operation. The description adds value by detailing the returned state components (pause reason, hit breakpoints, call stack), helping the agent anticipate the response. It doesn't mention edge cases like behavior when not paused, but the annotation covers the safety profile.

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

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

The description is a single sentence that front-loads the main action and resource, then lists specifics in a compact list-style format. Every word earns its place with no filler or repetition.

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

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

With zero parameters and an output schema available, the description sufficiently covers the tool's purpose and scope. It names the key elements of the debugger state, making it complete for a read-only state getter.

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

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

The input schema has zero parameters, so there is no parameter semantics to clarify. The description appropriately focuses on the tool's output instead, and the baseline for a no-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 opens with 'Get current debugger state' and enumerates specific elements: paused status, pause reason, hit breakpoints, and full call stack with file/line info. This clearly distinguishes it from sibling debugger tools like get_scope_variables or list_breakpoints.

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

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

The description provides clear context on what the tool offers (current state information), making it straightforward for an agent to decide when to use it. However, it does not explicitly mention alternatives or exclusion cases, 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?

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?

The description discloses a key behavioral trait: the tool depends on a prior marking step, not just a read of a live selection. This goes beyond the readOnlyHint annotation by explaining the stateful prerequisite. It does not mention the failure mode if no element is marked, but the output schema likely covers the return shape.

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

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

Two sentences: the first states the purpose, the second gives the prerequisite procedure. No filler or repetition, and the critical info 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?

For a simple getter with no parameters and an output schema, the description covers the essential 'how' and 'when.' The only minor gap is not stating the behavior when no element has been marked, but this is a low-complexity tool and the description is otherwise complete.

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

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

The tool has zero parameters, so the baseline is 4. The description provides no parameter-specific semantics because there are none, and no schema coverage is needed.

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

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

The description clearly states the tool's function: 'Get the element marked for MCP inspection.' The verb 'Get' plus the specific resource 'inspected element' distinguishes it from sibling getters like get_html or get_computed_style. The additional instruction on how to mark an element 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?

It provides explicit steps to prepare the element for inspection ('select it in the Elements panel, then run window.$0 = $0'), which is practical usage guidance. While it doesn't explicitly state 'use this when you need the inspected element reference,' the context implies it, and no alternatives are mentioned.

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 readOnlyHint=true, so the description carries the behavioral burden and does so richly. It discloses the capture start boundary, navigation pruning behavior, redirect-chain representation as one record per hop with shared requestId and `hop`, and the absence of WebSocket frames — all traits 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, every one earning its place: the first states core function and return fields, the second explains capture-window and navigation semantics with a sibling contrast, and the third covers redirects and exclusions. It is dense but highly scannable and front-loaded with the most essential 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 that an output schema exists, the description need not re-explain return values, and the 100% schema parameter coverage handles parameter documentation. The description adds the missing operational context — capture lifecycle, navigation pruning, redirect hop representation, and WebSocket exclusion — making it complete for correct invocation and result interpretation.

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%, and each parameter already has clear descriptions covering limit, status, requestId, urlFilter, headerKeys, resourceType, and enums. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource — 'Return HTTP requests captured from the connected tab' — and enumerates the exact fields returned (method, URL, resource type, status, transferred size, duration, initiator, failure reason). It also distinguishes itself from get_console_logs by noting the pre-connect history difference, making its purpose unmistakable among siblings.

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

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

The description clearly communicates when data is available (only after server connection), when it is not (pre-connect requests), and what happens across navigation (pruning). It also gives exclusions such as WebSocket frames. However, it does not explicitly state when to prefer this tool over closely related siblings like get_network_response_body or clear_captures, so it falls just short of full usage 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?

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?

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?

The readOnlyHint annotation already indicates a safe read operation. The description adds the detail that it refers to the currently connected tab and that it's from `document.title`, which provides minor context. However, it doesn't describe the return format or any edge cases, though these are not critical for such a simple tool.

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

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

The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and resource, and the technical detail is in parentheses. This is maximally concise.

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 getter with no parameters and no output schema, the description fully covers what the tool does. The low complexity means no further behavioral details are needed. The mention of `document.title` adds implementation clarity, making it complete.

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

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

The tool has zero parameters, so the description need not explain parameters. The baseline for zero-parameter tools is 4, and the description appropriately says nothing about parameters, as there is nothing to add beyond the empty schema.

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

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

The description clearly states the tool gets the title of the currently connected tab, with a specific verb ('Get') and resource ('title of the currently connected tab'). It also references `document.title` for exactness. This distinguishes it from sibling tools like get_url or get_html.

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

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

The description implies clear usage: use when you need the title of the current tab. While it doesn't explicitly exclude alternatives or name a sibling, the purpose is so self-evident that no further guidance is necessary. The context is clear, but there's no explicit comparison to 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 provide readOnlyHint=true, and the description adds context by specifying it operates on the 'currently connected tab' and reveals the underlying `location.href` attribute. This clarifies scope without contradicting 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?

One sentence, concise and front-loaded, with zero redundant words.

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

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

For a getter of the current tab's URL, the description is complete. It states the exact resource, the implementation, and the read-only safe behavior covered by annotations. No output schema needed since the value is self-evident.

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 there is no ambiguity to resolve. Baseline for no params is 4, and the description adds no unnecessary parameter details.

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 'Get the URL of the currently connected tab' with a specific verb and resource, and includes the `location.href` implementation detail. This unambiguously distinguishes it from sibling tools like get_title or 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 description makes the tool's purpose self-evident, implying usage when the current tab's URL is needed. However, it does not explicitly state alternatives or exclusions, so it falls short of full 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 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 indicate readOnlyHint: true, which the description reinforces by using 'List.' The description adds workflow context about presenting the list to the user and proactively calling it when unsure, which goes beyond the annotation's minimal information. However, it does not disclose potential ordering or pagination behavior, though for a simple list tool this is minor.

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. The first sentence states the core function, the second provides usage guidance. Every word earns its place, with no redundancy or 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?

For a zero-parameter list tool with an output schema and a clear read-only annotation, the description fully covers what the tool does, when to use it, and how to handle the results. It is complete for its simplicity, leaving 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?

There are zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details, and the schema is empty because no input is needed. No additional parameter semantics are required.

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 function: 'List all open Chrome page tabs with their targetIds, titles, and URLs.' The verb 'List' is specific and the resource ('Chrome page tabs') is unambiguous, distinguishing it from sibling tools like switch_tab or get_title.

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

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

Provides explicit when-to-use guidance: 'When you are unsure which tab to inspect, call this proactively to discover available tabs, then present the list to the user and ask which one to switch to.' It also offers an exclusion: 'do NOT tell the user to switch tabs manually in Chrome,' clearly positioning this tool as the alternative to manual user action.

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 only a title annotation (no readOnly/destructive hints), the description carries the full burden. It discloses the immediate pause behavior and hints at the halted state by mentioning inspection of the call stack. However, it does not mention that execution remains suspended until an explicit resume action is taken, which is a notable behavioral detail. This is a moderate gap for a debugger control tool.

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

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

The description is exactly two sentences. The first sentence states the core action with the adverb 'immediately' adding useful nuance. The second sentence points to a supporting tool. There is no fluff or redundancy—every word earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description is complete: it states what the tool does and offers a follow-up action. The sibling list shows this is part of a debugging suite, so the lack of extensive detail is acceptable. The description fully covers the tool's simple purpose.

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 0 parameters and an empty input schema, so per the rubric the baseline is 4. The description adds no parameter-specific semantics because none are needed. The schema already covers everything, and the description does not attempt to invent parameters.

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

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

The description clearly states the action: 'Pause JavaScript execution immediately.' This is a specific verb+resource that distinguishes it from sibling tools like resume_execution, step_over, and get_debugger_state. The follow-up sentence provides additional context about its role in the debugging workflow.

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

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

The description implies when to use the tool (to pause execution) and provides a clear next step: 'After pausing, use get_debugger_state to inspect the call stack.' It does not explicitly state when not to use it or discuss alternatives, but the context is clear and the sibling tool reference helps orient the agent.

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

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

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?

There are no behavioral annotations (no readOnlyHint or destructiveHint), so the description must carry the full burden. It states the core operation but does not disclose potential side effects, error cases (e.g., calling when execution is already running), or return values. This is minimal but not misleading, earning a borderline average score.

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

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

The description is a single, front-loaded sentence that communicates the action and trigger condition without unnecessary words. It is appropriately sized for a tool with no parameters and no complex semantics.

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

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

The tool is simple with no output schema, but the description explains when to invoke it (after a breakpoint or pause) and what it does (resume execution). While it lacks detail on error behavior or side effects, this is a minimal debugger control operation, and the description is sufficient for an agent to use it correctly in most scenarios.

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

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

The input schema has zero properties, meaning there are no parameters to describe. Per the rubric, a zero-parameter tool receives a baseline score of 4 because the description cannot add parameter 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 clearly states the specific action ('Resume') applied to the resource ('JavaScript execution') and the condition ('after a breakpoint or pause'). This distinguishes it from sibling tools like pause_execution and the step_* commands, which serve different debugger control functions.

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

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

The description gives clear context for when to use the tool ('after a breakpoint or pause'), implying it should be used when execution is paused. It does not explicitly mention alternatives or exclusions, but sibling tool names like step_over and step_into signal that resume is for continuing normal execution, providing adequate 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?

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 include idempotentHint=true, which already communicates that repeated calls are safe. The description adds no extra behavioral context such as whether existing breakpoints are overwritten, persistence, or side effects. With annotations present, the bar is lower, but the description still adds minimal value beyond the schema.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the essential purpose and selection criteria in under 15 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 a fully descriptive schema and an output schema present, the description only needs to summarize the core action, which it does. It does not mention optional parameters like condition or columnNumber, but their absence is acceptable since the schema covers them. The description is sufficient for an agent to select and invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions URL (exact or regex) and line number, but those are already fully described in the schema. It does not add additional meaning about condition, columnNumber, or precedence rules, which are also covered by the schema.

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

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

The description clearly states the action ('Set') and resource ('breakpoint'), and specifies the key inputs (URL exact or regex + line number). It distinguishes this from sibling tools like remove_breakpoint and list_breakpoints by focusing on creation.

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 for when to use this tool (to create a breakpoint) by naming the selection method (URL exact/regex) and line number. It does not explicitly mention alternatives or when not to use it, but the context is unambiguous for a simple tool. No exclusions are needed given the sibling list.

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

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

No annotations beyond the title are provided, so the description carries the burden. It discloses that it returns the new call stack position, which is valuable. However, it does not mention potential side effects like changing debugger state explicitly, nor prerequisites like a paused debugger, leaving some behavioral details implicit.

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

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

The description is a single, front-loaded sentence that states the action and the return value. Every word is necessary; no filler or redundancy. Perfectly concise.

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 tool with no parameters and an output described in the text, the description is largely complete. It lacks explicit mention of prerequisites (e.g., debugger must be paused) and potential error conditions, but these are reasonably inferred from the sibling context and debugger domain.

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 baseline is 4. The description adds no parameter information, which is appropriate since there are none. No further elaboration is needed.

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

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

The description uses a specific verb ('step into') and resource ('the function call on the current line'), clearly distinguishing it from sibling tools like step_over and step_out. The purpose is immediately obvious and unambiguous.

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

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

The description implies its usage (to enter a function call) but does not explicitly state when to use it over alternatives like step_over or step_out. No exclusions or prerequisites are mentioned, making it functionally clear but with implied guidance only.

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 provide a title, no behavioral hints. The description does disclose that execution pauses and that a new call stack position is returned, but it does not mention that the debugger must already be paused or that this mutates debugger state. This is partial transparency.

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

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

Two sentences, no filler. The description is front-loaded with the action and immediately gives the return value. Every word earns its place.

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

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

For a zero-parameter debugger command, the description covers the action and return value sufficiently. However, it omits any reference to prerequisites (e.g., execution must be paused) or side effects beyond pausing, slightly reducing completeness.

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

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

The tool has zero parameters, and schema coverage is 100%. With no parameters to document, the baseline is 4, and the description adds no param info needed.

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

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

The description clearly states the action: 'Step out of the current function and pause at the caller.' This is a specific verb+resource phrasing that distinguishes it from siblings like step_over and step_into.

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

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

The description implies when to use the tool (when you want to exit the current function), but it does not explicitly contrast it with alternatives such as step_over or step_into. No exclusions or alternative conditions are provided.

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

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

Annotations only provide the title, so the description carries the burden of behavioral disclosure. It explains that execution pauses at the next line, that function calls are not entered, and that the new call stack position is returned. This is adequate but does not mention potential edge cases (e.g., behavior at function boundaries) or that execution must already be paused.

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

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

The description is a single sentence that is front-loaded with the primary action, concise, and contains no fluff. Every word 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 that there are no parameters and no output schema, the description fully covers the tool's behavior and return value. It is sufficiently complete for an AI agent to understand how to use it correctly.

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

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

The input schema is empty (0 parameters), so the baseline is 4 per the rubric. The description does not need to explain parameters as there are none.

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

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

The description clearly states the tool's action: execute the current line and pause at the next line. It explicitly notes that it does not enter function calls, which distinguishes it from sibling tools like step_into. The return value (new call stack position) is also stated.

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

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

The description gives clear context for when to use: when you want to execute a line without stepping into function calls. The phrase 'does not enter function calls' serves as a when-not condition, but it does not explicitly name alternative tools like step_into or step_out. However, the implied usage is clear.

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

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

With only a title annotation (no readOnly/destructive hints), the description carries the burden of disclosing behavior. It states the action ('Switch the MCP connection') and gives a prerequisite, but it does not explicitly describe the effect on subsequent commands, error behavior, or reversibility. This is a moderate level of transparency, sufficient for a simple state-changing tool.

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

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

The description is two sentences with no redundant words. It is front-loaded with the core action and includes a practical usage hint. Every sentence earns its place.

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

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

The tool has a single parameter and an output schema (not detailed here). The description explains what the tool does and the prerequisite for the parameter, which is adequate for a simple switching tool. It could mention the persistent effect on subsequent MCP calls, but 'Switch the MCP connection' sufficiently implies that. Overall, it is complete for this complexity.

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

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

Schema description coverage is 100%: the parameter targetId is described as 'Target ID from list_tabs.' The tool description reinforces this by saying 'Use list_tabs first to get available targetIds.' The description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's action: 'Switch the MCP connection to a specific Chrome tab.' This uses a specific verb ('switch') and resource ('Chrome tab'), and it distinguishes itself from siblings like list_tabs (listing) and get_url (reading). The purpose is unambiguous.

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

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

The description provides explicit guidance: 'Use list_tabs first to get available targetIds.' This tells the agent when to use this tool and what prerequisite to satisfy. It does not explicitly name alternatives or exclusions, but for a simple switching operation the context is clear.

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