waitForSpecificPause

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.