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

With no annotations, the description fully carries the behavioral burden. It discloses the need for prior user confirmation, the requirement for a unique substring, and instructs relaying the '_ui' field. It implies a state change (connecting) but does not cover failure modes or side effects, so not 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?

The description is well-structured with a numbered step marker, mandatory instructions, and concise specifications. Every sentence is purposeful—prerequisites, constraints, and output handling—with no fluff.

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

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

Given there is no output schema, it explains the '_ui' field relay. It covers prerequisites, workflow, input constraints, and output handling. It might benefit from noting error cases (e.g., if targetUrl not found), but for a connection tool it is sufficiently complete.

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

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

Schema coverage is 100% and both parameters are described in the schema. The description adds critical semantic value: targetUrl must be a unique substring confirmed by the user, and port has a default. It clarifies the usage context beyond the schema, enhancing understanding.

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

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

The description explicitly states 'Connect the debugger to a specific Chrome tab', using a specific verb and resource. It clearly differentiates from sibling tools like listTargets (which lists) and startDebuggingSession (which starts a session), and ties into a numbered workflow step.

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 mandatory prerequisites and exclusions: 'MANDATORY: call listTargets first... wait for their explicit URL confirmation', 'NEVER guess the URL. NEVER skip user confirmation'. This gives clear when-to-use and workflow guidance, including how to obtain the targetUrl.

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

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

With no annotations provided, the description must carry the behavioral disclosure. It clearly states it disconnects the session and clears in-memory pause state, which is beyond just the name. It doesn't mention side effects on breakpoints or reconnection, but for a simple disconnect operation, this is sufficient.

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 clearly state the action, the effect (clearing pause state), and the recommended usage context ('before connecting again'). No 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?

For a simple tool with no parameters and no output schema, the description covers the action, side effects, and usage context. It's complete enough for an agent to decide when to use it, though it doesn't mention any potential errors or whether disconnect is idempotent.

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 secret, so parameter explanation is unnecessary. The description doesn't need to compensate for anything. Per the instructions, 0 params gives a baseline of 4, which 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 function: 'Disconnect the current Chrome debugging session and clear in-memory pause state.' It uses a specific verb ('disconnect') and resource ('Chrome debugging session'), and distinguishes it from siblings like 'connect' and 'resume' by focusing on termination and clearing pause state.

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 instruction to 'use this to explicitly end a debug session before connecting again' gives clear context for when to use the tool. It implicitly contrasts with reconnecting, but doesn't explicitly name alternatives or exclusions, which is acceptable given the simplicity of the tool.

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

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

With no annotations, the description carries the full burden. It explains the evaluation context and common uses, but does not warn that arbitrary JavaScript evaluation may have side effects on the debuggee state (e.g., calling methods can mutate). This is a notable gap for a potentially unsafe operation.

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

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

Three sentences, each earning its place: defines the action and context, enumerates use cases, and positions it relative to getScopeVariables. No fluff 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?

The description is adequate for selecting the tool, but lacks important caveats such as side-effect risk and behavior when not paused. Since there is no output schema, the description should clarify what the evaluation returns, but this is partially mitigated by the straightforward nature of evaluating an expression.

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

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

Schema coverage is 100% for both parameters, so baseline is 3. The description adds value beyond the schema by providing concrete expression examples (this.state, JSON.stringify(obj)) and clarifying that frameIndex selects the call frame context, enhancing understanding of the expression parameter.

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

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

The description uses a specific verb ('Evaluate') and clearly identifies the resource ('any JavaScript expression in the context of the currently paused call frame'). It distinguishes itself from sibling getScopeVariables by noting it complements that tool for values not directly visible in scope.

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

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

It explicitly lists use cases: inspect nested objects, call methods, compute derived values, verify conditions. It also names getScopeVariables as the complementary alternative, giving clear contextual guidance without explicit exclusions.

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

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

The description discloses the primary behavior (forcing a pause) but does not mention potential side effects like whether a debugger must be attached or if the pause is persistent. Since annotations are absent, some additional detail could be provided.

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

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

The description is concise, with the action stated first and the use case in the second sentence. It is well-organized and front-loaded.

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

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

The description is adequate for the tool's simplicity, but it omits any mention of error cases or prerequisites (e.g., need for an active debugging session). This is a minor gap.

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

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

The tool has no parameters, and the description correctly does not attempt to explain any. Schema coverage is complete, so no additional parameter info 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 forces the debugger to pause at the next JavaScript statement, with a specific verb and resource. It distinguishes itself from setBreakpoint by noting when it is useful.

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

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

Explicit guidance is given: useful when source code cannot be modified and setBreakpoint is not feasible, implying when not to use it.

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

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

With no annotations, the description carries full transparency. It details the behavior (returns scope variables grouped by type, skips global scope) and the expected context (paused state). No destructive side effects are implied, and the read-only nature is evident.

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

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

The description is concise and well-structured, covering purpose, timing, result formatting, and parameter usage in a few sentences. Every sentence provides valuable information without redundancy.

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

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

The description is complete given the absence of an output schema. It explains what the tool returns (scope variables grouped by type) and provides necessary context (paused state, frame navigation). No critical gaps are apparent.

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

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

The only parameter, frameIndex, is fully described in both the schema and the tool description. The description adds meaningful detail on how to use it (default 0 for topmost, increment to go up the stack), satisfying the parameter semantics requirement.

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

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

The description clearly states the tool's purpose: reading all scope variables (local, closure, module) at the currently paused call frame. It is distinct from sibling tools, which focus on control (e.g., stepping, pausing) rather than inspection.

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

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

The description explicitly instructs when to call the tool ('immediately after waitForSpecificPause or waitForPause returns') and explains how to use frameIndex for parent frames. This provides clear, actionable usage guidance beyond the schema.

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 notes it is non-blocking and returns current state, implying no side effects, but does not explicitly state read-only behavior. Since no annotations are provided, the description mostly covers transparency but could be more explicit about 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 concise, using two clear sentences without unnecessary verbosity, and is well-structured.

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

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

It includes a list of return fields (connected, paused, targetUrl, etc.) and provides usage context, making it self-contained for the user.

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, and the description does not reference any, so there is no ambiguity or missing information.

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

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

The description clearly states that the tool returns the current connection and pause state immediately, which precisely defines its purpose.

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

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

It explicitly recommends using this tool for polling instead of waitForPause when the client has a short request timeout, providing concrete guidance on when to use it.

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

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

With no annotations present, the description must fully disclose behavior. It details the dual-instance setup, port auto-detection, dryRun behavior, openDevTools effect, and fallback instructions to relay the command and _ui field. This is exceptionally transparent for a launch 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 well-structured with step markers and front-loaded purpose. It is longer than a single sentence but every sentence adds value, including dryRun, openDevTools, and fallback. The structure improves readability, though it could be slightly tighter.

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 6 parameters, no output schema, and no annotations, the description covers essential context: default port, dual-instance, auto-detection, dryRun behavior, and fallback action. It even mentions relaying the _ui field, compensating for the lack of output schema. It does not explain all possible return fields but is adequate for a launch action.

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%, meaning each parameter already has a description. The tool description reinforces defaults (port, user-data-dir) and adds practical usage context for dryRun and openDevTools, but does not introduce meaning beyond what the schema already provides. 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 clearly states it launches a dedicated Chrome instance with remote debugging enabled, specifying the resource (Chrome) and the exact action (launch). It distinguishes from siblings by indicating this is the first step in a debugging workflow and mentions a key differentiator (--user-data-dir for dual-instance).

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 the tool, such as being STEP 1, auto-detecting an active port to skip launch, and suggesting dryRun to preview for user confirmation. It gives concrete usage advice (e.g., relaying the command if automatic launch fails) but does not explicitly contrast with sibling tools like startDebuggingSession or connect.

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

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

No annotations are provided, so the description carries the burden. It discloses workflow constraints (must ask user, must wait), relays the '_ui' field, and implies a blocking behavior. However, it doesn't explain what happens if the port is wrong or if no tabs are available, or whether the operation is read-only (though 'list' implies it). The description adds significant context beyond just 'list tabs'.

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

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

The description is concise and front-loaded with the primary action, then adds mandatory workflow constraints. Each sentence serves a purpose (step indicator, listing requirement, user interaction requirement, safety instruction, relay instruction). It's slightly longer than strictly necessary but all content is valuable. No fluff.

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

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

For a simple list operation with one parameter and no output schema, the description is quite complete. It covers the workflow context, mandatory interactions, and what to do with the response ('_ui' field). However, it doesn't describe error handling (e.g., if the port is unreachable) or what happens if no tabs are open, which would make it fully comprehensive. Given the tool's simplicity, this is almost complete.

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

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

Schema coverage is 100% (the only parameter 'port' is fully described with default and type). The description does not add extra meaning to the parameter, but since the schema already documents it and there's only one simple parameter, the baseline 3 is appropriate. The description correctly doesn't repeat the 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 the tool lists open Chrome tabs for debugging, using a specific verb ('List') and resource ('open Chrome tabs'). It also distinguishes itself from siblings by mentioning it's a distinct step in a workflow, though it doesn't name an alternative. The multiple constraints (show list, ask user, wait) make its purpose unambiguous.

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

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

The description provides explicit when-to-use guidance (STEP 2), mandatory actions (show full list, ask which URL), and prohibitions (never skip, never guess, even with one tab). It also instructs to wait for user reply before proceeding to connect(), effectively telling when not to proceed. This fully satisfies the dimension.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions maintaining CDP connection and ensuring debugger statements resolve, which adds context beyond the schema. However, it doesn't specify what happens to the current page state, potential side effects (e.g., unsaved changes), or whether the operation is synchronous or asynchronous. The description covers critical workflow aspects but not all behavioral nuances.

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 fairly concise and front-loaded with the purpose, followed by usage guidance and the critical turn rule. The critical rule is highlighted with ⚠️ and CAPS, making it prominent. A slight deduction for redundancy (e.g., 'waitForSpecificPause' mentioned twice) but overall efficient.

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

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

Given the tool's moderate complexity (one optional parameter), the description covers the essential workflow context: when to call, what to do after, and why it's better than manual refresh. While it doesn't explain return values (no output schema), the description compensates with the critical turn rule and sequencing instructions. It's sufficiently complete for an agent to use 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?

The schema has 100% coverage with one optional parameter (ignoreCache) already described as 'Hard reload ignoring cache (default false)'. The description doesn't add extra parameter semantics but the schema suffices. Baseline 3 is appropriate since the schema handles the parameter explanation.

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 reloads the connected page via CDP, with a specific verb ('reload') and resource ('connected page'). It distinguishes itself from a manual refresh by emphasizing reliability and CDP connection maintenance, which differentiates it from potential sibling operations like launchChrome or connect.

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 instructions: after inserting debugger; or setBreakpoint(), before waitForSpecificPause/waitForPause. It also includes a critical turn rule with clear direction to call waitForSpecificPause in the same turn, and warns against ending the turn after reloadPage. This is comprehensive guidance with specific sequencing.

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

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

No annotations are provided, so the description carries the burden. It states the tool removes a breakpoint (mutating action) and requires the ID from setBreakpoint. It does not describe effects like whether the breakpoint is removed from the session permanently, any side effects, or errors if the ID is invalid. But given the tool's simplicity, the description adds some context 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 one concise sentence that clearly states the action and the parameter's origin. It is front-loaded with the verb and resource, 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 the tool's low complexity (single parameter, no output schema, no annotations), the description is sufficient. It explains the action and references the prerequisite tool (setBreakpoint). It could mention error cases or that the ID must be valid, but for a simple removal operation, this is adequately complete.

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

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

Schema description coverage is 100%: the schema already describes breakpointId as 'The breakpoint ID returned by setBreakpoint'. The description repeats this, adding no new semantic information. The tool description also mentions the ID source, but it's redundant. Baseline 3 is appropriate because the schema fully covers the parameter.

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

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

The description clearly states the tool's action: removing a previously set CDP breakpoint by its ID. It identifies the resource (breakpoint) and the specific action (remove), and references setBreakpoint as the source of the ID. It is distinct from siblings like setBreakpoint and resume, though it does not explicitly contrast with them.

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

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

The description implies when to use: after setting a breakpoint, and it mentions the ID comes from setBreakpoint, which provides context. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., clearing all breakpoints). It lacks exclusions or alternative tool references beyond the implicit link to setBreakpoint.

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

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

With no annotations, the description carries the full burden. It explains the key behavior ('ends the current pause'), adds a required follow-up action (remove temporary debugger statements), and tells the agent to relay the '_ui' field from the response. Minor gaps like failure behavior remain, but this is solid for a zero-parameter 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 three sentences and every sentence earns its place: purpose/timing, post-call cleanup, and user-facing response handling. It is front-loaded with the core action and contains no fluff.

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

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

Given the tool's low complexity, zero parameters, and lack of output schema, this description is sufficiently complete. It covers when to call it, what it does, what to do afterward, and what to relay from the response.

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 for parameter semantics is 4. The description needs no parameter-level guidance, and it appropriately adds no irrelevant parameter information.

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: 'Resume script execution' and immediately clarifies it 'ends the current pause.' This distinguishes it from sibling stepping commands and clearly identifies the tool's role in the debugging session.

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 says to use resume 'after collecting all needed variable data,' providing a clear usage condition. It does not explicitly exclude alternatives like stepInto/stepOut, but the sequencing context is strong enough for an agent to know when resume 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 annotations provided, the description carries the full burden for behavioral context. It discloses the CDP mechanism, that no source modification is needed, how URL matching works, and the need to reload. It does not state that a debugging session must be active, but the sibling context implies this.

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 long and front-loaded with the core purpose. Each sentence adds necessary information: what it does, how to match URLs, and the required follow-up action. No 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?

The tool has four parameters, no output schema, and no annotations, so the description must provide most of the usage context. It covers purpose, URL matching, and reload guidance. A minor gap is that it does not mention the need for an active debugging session, though siblings like connect and startDebuggingSession imply it.

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. The description adds meaningful semantics by explaining that full URLs are exact-matched while partial filenames/keywords are regex-matched, which is not evident from the schema alone.

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: setting a breakpoint at a script URL and line number via CDP. It distinguishes itself from siblings like removeBreakpoint and waitForPause by focusing on breakpoint creation and explicitly noting it is an alternative to inserting debugger statements.

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 explicit when-to-use guidance: use this when the source file cannot be modified and as an alternative to inserting debugger. It also provides a concrete follow-up action (call reloadPage) to ensure the breakpoint resolves.

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

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

With no annotations, the description carries full burden. It discloses return behavior (returns workflow + _ui field to relay verbatim) but doesn't clarify whether this tool performs any side effects — it doesn't say if it establishes a connection/launches a browser, or is purely informational. Given the zero-param nature, the omission is moderate.

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 critical 'CALL THIS FIRST' instruction and clear trigger keywords. The keyword list is long but functional. Slightly verbose but well-structured.

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

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

For a zero-parameter informational tool with no output schema, the description tells the agent when to invoke it, what it returns, and how to handle the response (_ui field). This is 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?

Zero parameters, so baseline of 4 applies. Nothing to document; the schema is empty.

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: 'start debugging session' entry point. Clearly distinguishes from siblings by being the mandatory first call ("CALL THIS FIRST... before any other tool") that returns the workflow. Purpose is unmistakable.

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

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

Extremely explicit when-to-use guidance: 'CALL THIS FIRST whenever browser-side debugging is needed — before any other tool.' Also provides an extensive auto-trigger keyword list and explicit exclusion guidance (before other tools).

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

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

With no annotations, the description must carry the transparency burden. It discloses that the tool is blocking and waits for the next pause, which is a core behavioral trait. However, it does not mention error conditions, potential timeouts (despite the timeout parameter existing in schema), or prerequisites like an active debugging session.

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

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

The description is extremely concise, front-loading the action and blocking nature. The additional suggestion to follow with getScopeVariables() adds value without waste. Every word earns its place, and the step label is minor but not intrusive.

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 one optional parameter and no output schema, the description covers the essential behavior and a recommended next step. It lacks mention of edge cases (e.g., what happens if no function call exists), but given the simplicity of the operation, it is reasonably complete for an agent to execute correctly.

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

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

The schema covers 100% of parameter descriptions (timeout) with a clear explanation, so the description does not need to elaborate. The description itself does not add any information about parameters, but the high schema coverage justifies a baseline score of 3.

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

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

The description clearly states 'step into the next function call, then wait until the debugger pauses again' which precisely defines the action. This distinguishes stepInto from stepOver and stepOut by the specific behavior of entering the function and waiting for a pause.

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

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

The description implies usage (e.g., when wanting to inspect inner-function state) and suggests a follow-up with getScopeVariables(), but it does not explicitly state when to use this versus alternatives like stepOver or stepOut. No exclusionary guidance is provided, though the blocking and stepping nature 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 no annotations provided, the description carries the burden. It discloses that the operation is BLOCKING and that it waits for the next pause, and mentions observing return value/calling context. However, it does not describe timeout behavior, prerequisites (must be paused), or failure cases when no caller 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?

Two concise sentences with no redundant content. The '[STEP 7] BLOCKING:' prefix provides context without verbosity.

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 step tool with one optional timeout parameter and no output schema, the description fully explains the action and intended use despite not covering timeout expiry or return format. The lack of an output schema is compensated by the clear purpose statement.

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

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

The only parameter (timeout) is fully described in the input schema with a default value. The description adds no additional parameter information, so it scores baseline 3 for a schema with 100% coverage.

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

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

The description states a specific action ('step out of the current function') and outcome ('wait until the debugger pauses again in the caller'). It clearly differentiates from sibling tools like stepInto and stepOver by specifying the caller context.

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 a clear use case: 'Use to observe the return value and the state of the calling context.' However, it does not explicitly contrast with stepInto or stepOver or state when not to use, so it lacks explicit exclusions.

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

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

No annotations are provided, so the description carries the burden. It explicitly discloses 'BLOCKING' behavior and that it waits until the debugger pauses again, which is essential for a control-flow tool. It does not mention timeout failure behavior or return value details, but the schema covers the timeout parameter, and the blocking trait is the key behavioral risk.

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 efficient sentence with a step tag and a 'BLOCKING' warning, followed by a direct operational instruction. Every word adds value, with no fluff or redundancy.

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

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

For a simple control-flow tool with one parameter and no output schema, the description covers the primary behavior (step over, block, wait) and suggests an immediate next step. It does not describe timeout edge cases or what happens if the pause never occurs, but this is a minor gap given the schema's timeout documentation and the tool's narrow scope.

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% for the single timeout parameter, so the schema already documents the parameter. The description adds no extra parameter semantics beyond implying that the tool waits (which aligns with timeout). This meets the baseline 3 but does not exceed it.

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

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

The description explicitly states the action: 'step over the current statement without entering function calls'. It clearly distinguishes from stepInto by saying 'without entering function calls' and from stepOut by anchoring on 'current statement'. The [STEP 7] context and follow-up instruction reinforce its specific role in the debugging flow.

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

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

The description gives a clear usage pattern: it is blocking, waits until the debugger pauses, and should be followed with getScopeVariables() to observe variable changes. It implicitly contrasts with stepping into functions, but it does not explicitly name alternatives or state when not to use this tool. Clear context but no exclusions.

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

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

No annotations exist, so the description carries full burden. It discloses blocking behavior, user notification before blocking, and the fallback nature. It could mention timeout behavior or error cases, but the critical behavioral traits are covered.

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

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

Every sentence serves a purpose: step label, blocking definition, notification behavior, same-turn constraint, and clear alternative. It is front-loaded and no filler is present.

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 no annotations and no output schema, the description covers purpose, usage prerequisites, alternatives, and behavioral alerts. It is complete for an AI agent to decide when and how to invoke this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions a user notification which relates to actionHint, but does not add substantial meaning beyond the schema's own parameter descriptions. No additional param context is provided.

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

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

The description clearly identifies the tool as a blocking call that waits for any debugger pause, listing specific pause types (breakpoint, debugger; statement, exception). It explicitly distinguishes from waitForSpecificPause by noting this is the fallback for unknown locations or non-specific 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?

Provides explicit when-to-use and when-not-to-use guidance: must be called immediately after reloadPage() in the same turn, prefer waitForSpecificPause when file/line is known, and use this only when location is unknown or setBreakpoint lacks a specific line. Also warns not to end the turn before calling.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states the blocking behavior, that execution stays paused after return (no auto-resume), and the implications for the agent's next actions. It also notes that it sends a user notification and explains the line-numbering offset. The description is transparent about the tool's side effects (pausing execution, notification) and constraints (must be called after reloadPage in same turn). This is exceptionally transparent for a tool without 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 concise yet dense with information. It is well-structured with clear sections: the blocking nature, the no-auto-resume warning, conditional instructions, call timing, notification behavior, line offset, and UI relay. Each sentence serves a purpose, and the use of emojis and bold text highlights critical points. Despite the length, it is front-loaded with the most important behavioral notes and is easy to parse.

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?

Considering the complexity of the tool (blocking, condition-dependent next steps, timing relative to reloadPage), the description is complete enough. It covers the workflow context (step 5b preferred), the return behavior (matched field), the required call sequence, and provides guidance on error handling ('matched=false' case). Since there is no output schema, the description fills the gap by explaining what to expect from the response and how to act on it. It also references related tools (getScopeVariables, resume) to provide a complete 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% (all 5 parameters described in the schema). The description adds value beyond the schema by explaining the purpose of the line parameter (offset for CDP 0-based lines) and emphasizing that urlFragment is a substring, not full URL. It also provides usage context for timeout and actionHint, and suggests values for lineTolerance. The description enriches the parameter semantics with practical guidance that is not present in the schema's short descriptions.

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

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

The description clearly states the purpose: the tool blocks and waits for the next debugger pause, then checks if it matches a target location. It specifies the action (wait for pause, check match) and the resource (debugger pause), distinguishing it from sibling waitForPause (which likely does not filter by location). The use of 'BLOCKING' and 'checks if matches target' differentiates it well.

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 usage guidance: it must be called immediately after reloadPage() in the same AI turn, and it prefaces with '[STEP 5b — PREFERRED]' indicating its place in a sequence. It also clearly states behavioral expectations: no auto-resume, and gives conditional next steps based on the 'matched' field (call getScopeVariables or resume and wait again). It mentions a notification to the user for the page action, and explains the line offset (editor line N → pass N-1). This goes beyond the schema and gives clear context for when and how to use this tool.

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