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

With no annotations, the description carries the full burden. It discloses the aggregation behavior, failure visibility, and conditional OpenAPI discovery. However, it does not mention that probe_openapi causes active network probing by default, nor any side effects or access implications of the discovery process.

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 compact sentences with no filler. The core outcome and primary output attributes are front-loaded, and the usage guidance follows naturally.

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 tool with no output schema, the description adequately conveys what the returned map will contain and why it is useful. It could mention the overall return shape more explicitly, but the listed fields give an agent enough to anticipate the result.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline expectation.

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-resource pair ('Build a map of the backend') and enumerates concrete output details (endpoint groups, collapsed ids, call counts, status codes, timings, failures, OpenAPI). It is clearly distinct from raw network request tools like network_get_requests, though it does not explicitly name a sibling.

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 states a clear use case: 'Use it to understand the API surface, and to see at a glance which calls are failing.' However, it gives no guidance about when to choose this over network_get_requests or other network/source tools, and no exclusions or alternative recommendations.

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 at all, the description bears full responsibility for behavior. 'Ask the running page' and 'actual interactive surface' make clear this is an inspection/discovery operation that reports on the live page rather than mutating it, and the inclusion of 'working selectors' discloses a key deliverble. It does not explicitly state side-effect-freedom or prerequisities, but the read-only intent is strongly conveyed.

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 first sentence front-loads purpose and concrete output categories; the second supplies a usage rule and rationale. Every clause earns its place.

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

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

For a no-parameter tool with no output schema, the description covers what the agent needs: when to call, why, and what will be returned. It could add the exact response shape or mention that a devtools/page connection is required, but those dependencies are reasonably inferred from sibling tools like devtools_connect and page_navigate.

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 an empty schema, so there is no parameter documentation burden. The description's only input-related obligation is to make clear the tool takes no arguments and can be invoked immediately, which it implicitly does.

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 concrete verb and resource ('Ask the running page what it is') and enumerates the exact information categories reterned: UI libraries, routing, frame count, and interactive elements with selectors. This clearly distinguishes app_discover from sibling DOM/UI tools like ui_click or dom_quer, which operate on known selectors rather than discovering an unfamiliar page.

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

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

The description gives explicit timing and context—'Call this once before driving an unfamiliar app'—and warns against guessing selectors. It does not name an alternative tool or give a when-not-to-use condition, but the intended placement in the workflow is unmistakeable.

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 of behavioral disclosure. It explicitly notes that the tool clears the console buffer but does not affect the browser's own console display, which is useful boundary information. It does not describe irreversibility in detail, but for a simple clear operation the key behavior is 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?

Two sentences, each earning its place. The first states the action and purpose; the second clarifies an important boundary. No filler 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 zero-parameter tool with no output schema, the description provides sufficient context: what it does, why to use it, and what it does not affect. 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 tool has zero parameters, so the schema already fully defines the input surface. The description does not need to add parameter-level detail. Baseline 4 is appropriate for a parameterless 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 states a specific verb and resource: 'Empty the console buffer.' It also explains the intent ('so that what you read next belongs only to the action you are about to take'), making the tool's role unambiguous. It is clearly distinct from siblings like network_clear or console_get_logs.

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 implies when to use the tool: before an action whose console output you want to isolate. It does not explicitly mention alternatives or exclusions, but the intended use case is evident enough for an agent to select it appropriately.

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 burden and does disclose important behavior: success returns a value, and failure returns full exception detail (message, 1-based line/column, URL, stack). It does not explicitly warn about potential side effects of arbitrary JS execution, though the phrase 'read app state' implies a read-oriented intent. This is a minor omission, not a major gap.

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

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

Three tight sentences, each earning its place: the action, the error behavior, and the usage alternative. The most important information is front-loaded in the first sentence. 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?

No output schema exists, so the return value and error detail provided in the description are essential and well-covered. For a tool with 3 well-documented params, this is sufficient, though a note on promise behavior when await_promise is false and a warning about side effects would make it fully 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%: every parameter already has a clear description. The tool description adds no parameter-level semantics 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 clearly states the specific action ('Run a JavaScript expression in the page and return its value') and distinguishes itself from the key sibling debugger_evaluate_at_frame by contrast ('use debugger_evaluate_at_frame instead when you are paused and need a local variable'). This makes it easy for an agent to select the right tool.

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

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

Explicitly gives a primary use case ('Use it to read app state') and names the alternative with a concrete condition ('use debugger_evaluate_at_frame instead when you are paused and need a local variable'). This is clear when-to-use and when-not-to-use 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?

With no annotations, the description carries the full behavioral burden. It discloses the capture semantics, the Chrome pre-attach limitation, and a workaround. It also implies a non-destructive read operation, though it does not mention that clear=true will empty the buffer or that include_agent hides DevCDP's own diagnostics.

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 with no filler. The core read action, incremental cursor pattern, and key limitation are front-loaded, and every sentence contributes useful operational 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?

For a six-parameter tool with no annotations and no output schema, the description gives a solid picture of what is returned, how to page through results, and the major environment constraint. It leaves some output-shape details unspecified, but the essential context for correctly using the tool is present.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds real value by explaining the cursor parameter as a nextCursor pattern from a previous call. It does not detail clear/level/limit/since/include_agent, but those parameters are already fully described in the input 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: 'Read console output captured since attach.' It also identifies the contents (logs, warnings, uncaught exceptions with file, line, and stack), which clearly distinguishes it from sibling tools like console_evaluate, console_clear, and network_get_requests.

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

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

The description gives practical usage guidance: pass cursor=nextCursor from a previous call for incremental reads, and note that pre-attach messages won't be replayed unless the action is reproduced or page_reload is called. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the context is clear enough for an agent to select this tool appropriately.

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 of behavioral disclosure. It implies a prerequisite (a paused call frame) but never states it explicitly, and it does not disclose that evaluating arbitrary JavaScript can have side effects, may throw, or may require an active debugger connection. This is a significant gap for an execution 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?

Two sentences with no wasted words. The first sentence front-loads the core function and scope; the second adds a practical purpose that helps an agent decide to use it.

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

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

Purpose, scope, and parameters are well covered, and the schema fully documents the arguments. However, with no annotations and no output schema, the description omits behavioral prerequisites, side-effect potential, and error behavior—information an agent needs to invoke this safely and correctly in a debugging workflow.

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 input schema already documents expression, depth, and frame_index meaningfully. The main description adds context about frame scope but no parameter-level detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

States a specific verb ('Evaluate') and resource ('scope of a paused call frame'), and explains why local variables and closures are accessible. This distinguishes it from generic evaluate tools like console_evaluate and runtime_evaluate_many, and the 'confirm a hypothesis' phrase clarifies the intended use.

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?

Clearly implies when to use: when a call frame is paused and the agent wants to verify a hypothesis with a real value. It does not explicitly name alternatives or exclusion conditions, but the paused-frame context is a strong and clear signal that alternatives like console_evaluate do not fit this scenario.

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 and it discloses the two most important behavioral traits: the payload is a snapshot captured at the last breakpoint, not live state, and the tool ships a staleness signal distinguishing a current pause from a resumed one. That directly prevents the classic misuse of treating stale data as live. It does not cover error behavior when no breakpoint has ever been hit, nor the prerequisite of an attached devtools/debugger connection, which the sibling set implies.

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?

Exactly two sentences (~50 words) with zero waste. The first sentence front-loads the composite payload and scopes it to the last breakpoint hit before introducing the alternative framing; the second sentence supplies the staleness disclosure. Every phrase earns its place and nothing repeats what the empty schema already says.

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-param aggregator with no output schema, the description sketches the return content at enought granularity — top-frame scope, console, network, plus a staleness flag — for an agent to decide whether to invoke it and how to interpret the result. The gaps are the no-breakpoint-hit edge case and the requirement of a live debugging connection, both moderately relevant given the sibling tools. Neither is fatal for an agent choosing 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?

The tool has 0 parameters with trivial 100% schema coverage, so the baseline is 4. The description reinforces that no input is needed ('captured automatically', 'in one call') and there are no enums or required fields to document. There is nothing more the description could meaningfully add about 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+resource: it retrieves everything captured automatically at the last breakpoint hit — top-frame scope, recent console output, and recent network requests — in one call. The 'instead of four' clause explicitly differentiates it from the individual console_get_logs / network_get_requests / debugger_get_scope family, and the em-dash list makes the exact resource 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?

'In one call instead of four' is an implicit but clear efficiency directive: use this tool when you want the aggregated capture in a single call rather than four separate retrievers. The staleness sentence ('Tells you whether the pause is still current or has already resumed') also states the specific situation where this tool adds value over a plain snapshot. However, it never names the alternative tools explicitly or says when NOT to use it (e.g., when only one data type is needed), 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?

With no annotations provided, the description carries the full transparency burden, and it does well: it discloses that nested objects/arrays are expanded, that `this` appears, and that any size-based omission is explicitly marked. This prevents an agent from incorrectly assuming truncated values are complete, which is valuable behavioral detail beyond the raw 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 three sentences, front-loaded with the core action, and every sentence adds useful information: scope context, expansion behavior, `this` inclusion, and the omission guarantee. There is 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?

For a tool with four optional parameters, no output schema, and no annotations, the description plus schema covers most of what an agent needs: what it reads, when it applies, and how results are represented. It could add a little more about what happens if the debugger is not paused, but it otherwise gives enough context to invoke the tool correctly.

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

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

The input schema already covers all four parameters with meaningful descriptions at 100% coverage, so the baseline is 3. The description adds general context about expanded objects but does not add specific parameter-level meaning; it correctly leaves parameter details to the schema.

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

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

The description uses a specific verb ('Read') and resource ('variables in scope at a paused call frame'), and immediately distinguishes this from sibling tools by highlighting that objects and arrays are expanded rather than shown as 'Object' and that `this` is included. This lets an agent identify the right debugger inspection tool without comparing schemas.

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

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

The intended context is explicit: this tool is for reading scoped variables while the debugger is paused at a call frame. It does not explicitly name alternatives like debugger_evaluate_at_frame, but the distinction is implied by focusing on scope inspection rather than expression evaluation, and no misleading guidance is present.

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 annotations, so the description carries the full burden. It transparently describes the returned information (reason, full call stack, file positions) and the special paused:false behavior when running. This gives the agent a clear behavioral model of the tool despite lacking 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 two sentences, front-loads the primary purpose, and includes the important running-state edge case without extra fluff. Every clause adds value, and the structure is easy 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 no output schema and no annotations, the description explains the main return fields: pause reason, call stack with function names and positions, and paused:false when running. It could go slightly further in describing the exact shape of the call stack entries, but it is largely complete for a parameterless 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 tool has zero parameters, so parameter documentation is not needed. The description adds useful context about what the returned state represents, aligning with the baseline for a no-parameter 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 clearly states what the tool does: it reports where execution is paused, including the reason and the full call stack with function names and 1-based file positions. It also explicitly covers the running-state case with paused:false, making the tool's purpose unambiguous and distinct from sibling debugger 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 implies when to use the tool: when execution is paused and you need the current location and call stack. It even signals that it can be used to check whether the page is running. However, it does not explicitly mention alternatives or state when not to use it, leaving some inference to 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?

With no annotations provided, the description carries the burden of behavioral context. It discloses that the tool reports binding status and explains the operational consequence ('An unbound breakpoint will never fire'), which goes beyond the tool name and gives the agent useful diagnostic knowledge.

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, each earning its place: the first states the tool's scope, the second adds a practical diagnostic use. The most important information is front-loaded, and there is no filler.

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

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

This is a simple zero-parameter tool with no output schema and no annotations. The description covers what is returned, the meaning of the returned data, and a concrete use case, so an agent has enough context to invoke 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 has zero parameters, so the 0-parameter baseline applies. There are no parameter semantics to clarify, and the description appropriately focuses on behavior and use instead.

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 names a specific verb and resource: 'List the breakpoints DevCDP has set'. It also adds a distinguishing detail, whether each breakpoint is bound to executable code, which clearly separates it from breakpoint creation/removal and other debugger commands.

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 a concrete trigger condition: 'check here first when a breakpoint is not hitting'. This gives clear guidance on when to use the tool, though it does not explicitly name alternatives or state 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 provided, the description carries the full burden of behavioral disclosure. It effectively explains that the page is frozen while held, and importantly, that DevCDP auto-releases after maxPauseMs if not resumed, so no human intervention is needed. This reveals timeout and safety behavior beyond a simple 'pause' statement, which is valuable for an agent.

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 filler. The core action and purpose are front-loaded, and the auto-release behavior is stated efficiently. The colloquial reassurance about never having to press resume in Chrome adds helpful context without bloating the description.

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 tool with no annotations and no output schema, the description is largely complete: it explains what happens, what the page state is, and how long the pause can last. It does not explicitly describe return values or mention sibling tools for earlier resume or stepping, but those are minor gaps given the tool's simplicity.

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

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

The tool takes zero parameters, and the schema already documents this with an empty properties object, so there are no undocumented arguments. The description adds relevant context by mentioning maxPauseMs as a behavior, though it is not a parameter. This meets the baseline for parameterless tools.

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

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

The description states a specific verb and resource: 'Pause JavaScript execution at the next statement the page runs.' It also clarifies the holding behavior and distinguishes itself from other debugger tools by focusing on pausing rather than stepping, resuming, or evaluating. The phrase 'so you can inspect and step' makes the purpose concrete.

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 this tool: when you want to freeze page execution to inspect or step through code. However, it does not explicitly mention alternatives or when not to use it, such as using debugger_set_breakpoint for a specific location or debugger_step_over after pausing. The guidance is clear enough but not exhaustive.

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 and discloses the key side effects: removing all DevCDP-set breakpoints and resuming the page if paused. It adds useful cleanup semantics beyond the bare tool name, though it does not mention idempotence or what happens when no breakpoints are present.

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, both load-bearing: the first states exactly what the tool does, the second explains when to use it. No filler 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 zero-parameter tool with no output schema, the description is complete. It explains both the action and the practical cleanup scenario, leaving no ambiguity about invocation intent.

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 details because none are 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 identifies a specific verb and resource: 'Remove every breakpoint DevCDP set' plus the conditional resume action. This clearly distinguishes it from siblings like debugger_remove_breakpoint, which removes a single breakpoint, and debugger_resume, which only resumes.

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

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

The description explicitly states when to call it: 'Call this before handing the browser back to a human.' It gives a clear motivating context, though it does not name alternative tools or specify 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?

No annotations are provided, so the description carries the full burden. It clearly communicates the destructive side effect of removing a single breakpoint, but it does not mention behavior when the breakpointId is invalid, whether removal is reversible, or what state changes occur in the debugger session.

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

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

Two sentences, no filler. The core action is front-loaded, and the sibling alternative is given in the second sentence without repeating schema details or adding unnecessary context.

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 one-parameter mutation tool, the description is nearly complete: it states the operation, the identifier source is in the schema, and the sibling alternative is named. The main gap is the lack of any information about return values or error cases, though neither is essential for this straightforward removal 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 description coverage is 100%: the only parameter, breakpoint_id, is already documented as 'breakpointId from debugger_set_breakpoint.' The description adds no new parameter semantics beyond restating the breakpointId concept, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Remove'), a specific resource ('one breakpoint'), and the key identifier ('breakpointId'). It also distinguishes itself from the sibling tool debugger_remove_all_breakpoints, which is a clear point of confusion an agent would otherwise face.

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 routes the agent to the alternative: 'Use debugger_remove_all_breakpoints to clear them in one call.' This directly tells the agent when to choose this tool versus the sibling, with no inference required.

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 full burden. It discloses key behavioral context: resume is conditional and normal breakpoints auto-resume. It could additionally mention behavior when already running or after a step completes, but for a zero-parameter debugger control the core behavior is transparent enough.

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

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

Two short sentences, with the core action front-loaded and the conditional usage guidance compressed into the second sentence. No redundant or vague phrasing.

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 tool with no output schema, the description provides sufficient selection and invocation context. It explains both when to call the tool and when to avoid it, making it complete for an agent.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing for the description to clarify about arguments, and the input schema confirms no parameters 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 states a clear verb and resource ('Resume execution') and adds 'drop any hold,' which gives a precise operational meaning. It also distinguishes itself from normal breakpoint auto-resume and from sibling debugger controls like debugger_pause and stepping 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?

It explicitly lists when the tool is needed: after an explicit pause, after stepping, or after a breakpoint with auto_resume:false. It also states when it is not needed by explaining that breakpoints resume themselves by default, giving the agent clear selection 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?

With no annotations at all, the description carries the full disclosure burden, and it does so well. It reveals that URL substrings are resolved to exact scripts, original paths are translated through source maps, Chrome might fail to bind the breakpoint and the tool will report that honestly, and auto_resume affects whether the page stays frozen. The note that a paused execution is released after maxPauseMs regardless is especially valuable 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?

The description is three sentences with no filler. The core action and reporting promise are front-loaded, followed by the input-mode details and then the auto_resume guidance. Every sentence earns its place and contributes to correct invocation.

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 tool with five parameters, no output schema, and no annotations, the description is nearly complete: input modes, failure honesty, and pause/resume behavior are all covered. The main omission is lack of explicit routing to sibling tools such as debugger_set_breakpoint_at_function or debugger_list_breakpoints, but the description plus a detailed input schema is enough for an agent to invoke this 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?

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema: it explains substring resolution behavior for url and the source-map translation for original pre-bundling paths. It also adds context for auto_resume beyond its schema description, clarifying the automation-driven scenario and the timeout release 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 opens with a specific verb and resource: 'Set a breakpoint' in Chrome. It also commits to a distinctive behavioral promise, 'report honestly whether Chrome could bind it,' which makes the tool's purpose concrete. The accepted input modes (script URL/substring vs. original source path) clearly separate this from the sibling debugger_set_breakpoint_at_function even without naming it.

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 conditional guidance for the auto_resume parameter, telling the agent when to set it to true versus false and explaining the consequence of each choice. However, it does not explicitly say when to choose this tool over the function-based breakpoint sibling or the breakpoint-management siblings. That routing is only implied by the input-mode description, so the guidance is present but not 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?

With no annotations, the description carries the behavioral disclosure burden. It clearly explains that DevCDP resolves any function expression to its definition and breaks at its first statement. It does not cover breakpoint persistence or the return result, but the core runtime behavior is transparent enough for selection and invocation.

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 with no filler. The main behavior is front-loaded, examples are compactly integrated, and the sibling comparison appears at the end without bloating the description.

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 3-parameter tool with no output schema and no annotations, the description covers purpose, usage, and behavior well. It slightly lacks return-value expectations and breakpoint lifecycle details, but those are not critical for selecting and invoking 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 adds helpful examples like 'app.saveOrder' and 'MyClass.prototype.load', reinforcing the function_expression parameter, but the schema already documents the key semantics such as 'no call parentheses'. No additional parameter meaning 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 states a specific action: set a breakpoint on a named function without knowing its file. It also distinguishes itself from the sibling debugger_set_breakpoint by contrasting function-based vs file-and-line-based breakpoints, so an agent can select the right tool immediately.

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

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

It gives an explicit when-to-use rule: 'Use this when you know what runs but not where it is defined; use debugger_set_breakpoint when you already have a file and line.' This is direct, actionable guidance that names the alternative and the selecting condition.

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 annotations, so the description carries the behavioral disclosure burden. It explains pausing semantics, auto-resume behavior, maxPauseMs release, and where to get results (debugger_get_state, debugger_get_scope). While it doesn't mention side effects on breakpoints or what happens if not paused, the disclosed behavior is substantial and goes beyond a terse verb phrase.

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 compact: three sentences, each with distinct value—action, pause semantics, and postcondition/result location. It avoids tautology and structured redundancy. 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 zero-parameter stepping tool with no output schema, the description covers the action, preconditions ('from the current pause'), duration, and where to inspect results. It does not explicitly state an error condition if not paused, but that is a minor gap given sibling context and existing debugger state tools.

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 description coverage is 100% because there is nothing to describe. No parameter detail is needed, so this is effectively a non-issue; the description explains the behavior contextualizing the input-less call.

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 a specific action: 'Step into from the current pause and stop at the next statement'. The verb 'step into' is precise in the debugging context and the resource (debugger execution state) is clear. It distinguishes itself from siblings like debugger_step_over and debugger_step_out through the 'step into' phrase, and it also points to related state/scope retrieval 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 explains when it is used ('from the current pause') and the behavioral implication: 'Stepping implies you want the pause held, so it will not auto-resume between steps'. It also gives a boundary condition ('released automatically after maxPauseMs if you stop'). This is strong usage guidance for an agent deciding to use this tool.

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

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

With no annotations, the description carries the full burden and does it well: it discloses that the pause is held between steps, that the pause is auto-released after maxPauseMs, and that new location/scope can be retrieved via debugger_get_state and debugger_get_scope. This is meaningful behavioral context beyond a simple action statement.

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 tight sentences, each carrying distinct information: the operation, the pause lifecycle behavior, and how to observe the result. No filler 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 parameter-free tool with no output schema, the description covers the key post-conditions and where to find results. It does not explicitly state that the debugger must already be paused or what happens if it is not, and the phrase 'stop at the next statement' could be more precise about exiting the current function, but the overall guidance is sufficient for most calls.

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 the schema already fully covers this, so no parameter explanation is needed. The description's mention of maxPauseMs refers to a behavior/timing detail rather than a tool 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 states a specific action with 'Step out from the current pause' and gives a concrete result: 'stop at the next statement.' It clearly belongs to the debugger stepping family and is distinguishable from step_over/step_into by the operation named, though it does not explicitly contrast with those 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?

No guidance is given about when to choose step_out over step_over or step_into. The description explains pause-holding behavior but does not state the common use case, such as exiting the current function to return to a caller, nor any exclusions or 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?

With no annotations, the description carries the full behavioral burden and does it well: it discloses that the pause is held, that auto-resume is suppressed between steps, and that release still happens after maxPauseMs. It also tells the agent where to observe the results (debugger_get_state and debugger_get_scope), which is exactly the non-obvious, useful context an agent needs.

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 well-organised sentences: the first states the core action and result, and the second adds the consequential behavior and data-access pointers. Every sentence 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?

For a zero-parameter, no-output-schema command, the description is nearly complete: it defines the action, the pause semantics, timeout behavior, and where to retrieve resulting state. Minor gaps include not defining maxPauseMs, but in the debugger-devtools context this is an acceptable assumption.

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?

This tool accepts zero parameters, and the schema coverage is 100%. There are no parameter semantics to document, so the description cannot be expected to add parameter detail. The baseline for a zero-parameter tool applies.

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

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

The description states a specific verb and resource: 'Step over from the current pause and stop at the next statement.' It is clear and not a tautology, but it does not explicitly contrast itself with the sibling tools debugger_step_into and debugger_step_out, leaving some distinction to inference from the tool name.

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?

There is no explicit guidance on when to choose this tool over debugger_step_into, debugger_step_out, debugger_resume, or other stepping alternatives. The description explains behavioral consequences of stepping but not selection criteria, so an agent must infer usage context from sibling names and the debugger state.

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

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

With no annotations provided, the description carries the full burden of explaining behavior. It clearly portrays a read-only inspection operation and discloses the range of information returned, including file search paths and error cases such as failed parses and unrecognized settings. It could be slightly more explicit about having no mutation side effects, but 'Show' plus the detailed listing strongly 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 two sentences with no filler. The primary verb and purpose are front-loaded, followed by a compact enumeration of the tool's outputs and then a practical usage note. 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 is a straightforward read-only introspection command with two optional parameters. The description compensates for the lack of an output schema by explaining what information will be shown, and it also gives a practical usage context. Nothing essential is missing for an agent to select and correctly invoke 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 description coverage is 100%, so the input schema already fully documents both parameters (group and changed_only) with defaults and meanings. The tool description does not add additional parameter-level detail, which is acceptable given the schema already carries that load.

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: 'Show every DevCDP setting' and then details exactly what will be displayed: effective value, provenance, searched/loaded files, and parse failures. This clearly differentiates it from the sibling devcdp_settings_init, which is about initialization 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 states when to use the tool: 'Use it before changing configuration, and to check a change actually took effect.' It provides clear context for the appropriate moment to invoke it, though it does not name alternatives or give explicit when-not-to-use 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?

With no annotations, the description carries the full behavioral burden. It clearly discloses that the tool writes a file, includes every option with current values and explanations, and refuses to overwrite unless explicitly asked. This is meaningful behavioral context beyond a simple 'write settings' statement, though it does not mention error handling or filesystem side effects beyond overwrite.

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

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

Two tight sentences convey the tool's purpose, content of the file, and overwrite behavior without wasted words. The primary action is front-loaded, and the safety caveat is placed immediately after. 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?

For a low-complexity tool with two optional parameters, full schema coverage, and no nested objects or output schema, the description is reasonably complete. It explains what the file contains and the overwrite guard. It could mention what happens on refusal or what the tool returns, but these are minor gaps given the tool's simplicity.

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 already provides 100% coverage of both parameters ('path' and 'overwrite') with descriptions and defaults. The tool description adds no new parameter-level detail, but the phrase 'unless you say so' loosely maps to the overwrite parameter. This meets the baseline for schema-driven semantics but adds little beyond 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 states a specific action ('Write a settings file') with a clear resource ('every option with its current value and an explanation'). It also conveys the file's purpose ('so it can be edited by hand'), distinguishing it from generic settings readers/writers. It does not explicitly name sibling tools, so it stops short of perfect differentiation.

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 it: to create an editable, hand-maintainable settings file. It also implies the overwrite condition. However, it does not explicitly say when to prefer this tool over the sibling 'devcdp_settings' or any alternative, nor does it describe exclusions. Usage context is inferable but not stated.

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 takes on the burden of disclosing side effects. It clearly states that the tool claims the tab, blocks other DevCDP sessions, marks the tab visibly, and reports pre-attachment loaded state. This is good transparency, though it does not mention cleanup or failure behavior.

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

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

The description is three compact sentences that front-load the core purpose, immediately state the key side effect, and finish with a clear usage directive. Every sentence earns its place with 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?

For a moderately complex connection tool, the description covers the essential preconditions and consequences: when to call it, what it claims, what it starts observing, and what it reports. The lack of an output schema and the absence of annotations mean some return-shape details are unspecified, but the important contextual guidance is present.

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

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

The input schema has 100% description coverage, so every parameter is already documented with type, default, and meaning. The tool description does not need to repeat these, and it does not add significant extra parameter-level meaning beyond what the schema provides.

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

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

The description uses a specific verb ('Attach') and a clear resource ('a Chrome tab over the DevTools Protocol'), and it explains the immediate effect: start observing console, network, DOM, and debugger activity. This clearly distinguishes it from sibling tools like devtools_status or devtools_disconnect.

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 says to call this once at the start of a debugging session, giving the agent a clear temporal trigger. It does not explicitly discuss alternatives or when not to use it, but the guidance is sufficient for a session-initialization 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 present, the description carries the full burden and fully discloses side effects: resumption, removal of session-set breakpoints only, badge removal, and tab-claim release. It even conditions one effect ('if it is paused at a breakpoint') and scopes another ('we set').

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?

A single front-loaded sentence expresses the core verb first, then a tight colon-separated list of side effects, ending with the usage directive. No filler 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 parameterless cleanup tool with no output schema, the description covers what it does, the conditionality of one action, the side effect on the tab claim, and when to call it. Nothing necessary for selecting and invoking it is missing.

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

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

The tool has zero parameters and an empty schema, so parameter semantics are trivially covered; the baseline is 4. The description reinforces that invocation requires no arguments.

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 'Detach cleanly' and enumerates concrete effects: resume paused page, remove breakpoints, remove badge, release tab claim. This clearly identifies a distinct cleanup operation and contrasts with sibling devtools_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?

It gives an explicit trigger: 'Always call this when you are done.' This tells the agent exactly when to invoke the tool and implies it is the terminal cleanup step, so no alternative cleanup tool is needed.

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 behavioral context. It does so by disclosing the exact state it reports: attached tab, entry counts, debugger pause state, and buffer eviction. It does not explicitly state read-only or side-effect-free behavior, but the status nature and accounting language make this reasonably clear.

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 dense, well-structured sentence with a colon-led list. It is front-loaded with the core purpose and contains no filler or redundant 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?

For a zero-parameter status tool with no output schema, the description fully previews the kind of information returned: attached tab, buffer counts, debugger pause state, and eviction status. Nothing essential for invoking this tool correctly is missing.

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

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

The input schema has zero parameters, so there is no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.

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 defines what the tool reports—connection health, attached tab, buffer counts for console/network/script, debugger pause state, and eviction. It is specific and resource-focused, though it lacks an explicit verb and does not directly name sibling tools for differentiation.

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 purpose implies when to use it—when an agent needs a status/health summary of the devtools connection and buffers—but it provides no explicit when-to-use guidance, exclusions, or alternatives. It is adequate but inferred rather than stated.

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 behavioral burden, and it delivers by explaining the detection mechanism is structural (ARIA roles, dialog element, stacked-overlay geometry) and framework-agnostic. This helps an agent trust results across UI stacks. It does not explicitly state that the tool is read-only, but 'detect' and the structural explanation strongly imply non-destructive inspection.

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 with no wasted words: the first defines what it detects, the second explains the mechanism, and the third gives the calling context. The most important information 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 low-complexity tool with one optional parameter and no output schema, the description is largely complete: it names the output fields, explains the detection method, and gives usage timing. It could be slightly stronger by stating the empty-result behavior when no dialog is present, but that 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 frame parameter is fully described in the schema, and the tool description does not repeat it. The schema text is slightly inconsistent (default 'all' but says 'main (default)'), so a brief clarification would help, but with 100% schema coverage 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 uses a specific verb ('Detect') with a concrete resource ('modal dialogs, alerts and confirmation overlays') and states the exact information returned (title, message, button labels). It also clarifies the 'visible right now' scope, which distinguishes it from broader DOM or wait-oriented 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 gives an explicit trigger: 'Call it after any action that might raise a prompt.' This clearly states when to use the tool. It does not explicitly name alternatives or say when not to use it, but the timing guidance is strong enough for an agent to select it 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?

No annotations are provided, so the description carries the burden. It clearly indicates this is a read/list operation and conveys the tool is safe enough to be a first call. It does not explicitly discuss side effects, output size, or performance, but it is not misleading and discloses the essential behavior.

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

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

Two concise sentences with no filler. The action is front-loaded, the return content is summarized, and the second sentence provides a clear usage recommendation.

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 listing tool with no required parameters and a complete schema, the description sufficiently explains what it returns and when to call it. It could say more about the exact output structure, but an agent has enough to select and invoke it correctly.

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

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

Schema description coverage is 100%, with both optional parameters documented in the schema. The description adds only the context of 'docs root' but does not need to compensate since the schema already explains root and max_files.

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

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

The description states a specific verb and resource: 'List the documentation available under the docs root, with each file's headings.' It also distinguishes itself from search by framing this as an orientation call 'before searching,' which separates it from tools like docs_search.

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

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

It gives explicit usage context: 'A good first call when you do not yet know the app's vocabulary' and places it 'before searching.' It does not explicitly name sibling alternatives or state when not to use it, but the intended timing 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, the description carries the burden of behavioral disclosure. It states the exact search corpus, the returned artifact (passages with file and line), and the configurable docsRoot. For a read-only search tool, this is sufficient disclosure; there are no destructive or side-effect behaviors that need explaining.

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 with no filler: action and scope first, then usage guidance, then configuration note. 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 description plus the fully documented schema provide everything needed to invoke this tool correctly: what it searches, what it returns, when to use it, and how to configure the docs root. No output schema exists, but the high-level return information is adequate for a passage-search 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 adds context about the docs root and result passages, but it does not add much meaning to specific parameters beyond what the schema already documents.

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 names a specific verb ('Search'), a specific resource ('the project's own documentation — README and any markdown/text/pdf docs under the configured docs root'), and the result shape ('matching passages with file and line'). This clearly distinguishes it from sibling tools like source_search or docs_outline by corpus and operation.

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 concrete when-to-use scenario: 'Use it to learn what a screen, field or business term means in this app, instead of inferring it from the UI.' It does not explicitly name alternative tools or exclusions, but the context is clear enough for an agent to route to it appropriately.

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 carries the behavioral disclosure burden. It does reveal non-obvious behavior: only the first matching element is returned, and the output is truncated. The 'byte budget' wording is slightly inconsistent with the schema's 'characters' description, but the core operation and scoping are transparent.

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 filler. The operation is front-loaded, and the comparison with dom_query is placed in the second sentence as useful context.

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?

This is a simple read-only tool, the schema covers all parameter details, and the description explains purpose, selector scoping, inner/outer mode, and truncation. Minor gaps around no-match behavior and exact return wrapping remain, but they are not critical for a tool that returns HTML.

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?

All four parameters already have full descriptions in the schema, so the baseline is 3. The description loosely reinforces the inner/outer behavior and truncation, but it does not materially improve parameter understanding, and the byte-budget phrasing conflicts with max_bytes being described in characters.

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 names the specific operation: get the inner or outer HTML of the first element matching a selector, with truncation. It also distinguishes itself from the sibling dom_query by explaining that it is useful when structure cannot be inferred from dom_query alone.

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

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

The description provides a practical use case and names dom_query as the alternative to consider. It does not list exclusions or other sibling tools, but the context is clear enough for an agent to choose this tool when raw HTML markup is needed.

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 disclosure burden, and it does well by revealing that the tool returns a stateful buffer of changes since the last call and explaining the diagnostic meaning of empty results. It does not explicitly mention the default clear/drain side effect, though that is described in the input schema; the core behavior is still transparent.

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 compact sentences deliver the core definition and the practical use case with no filler. The most important information—what the tool returns and its temporal scope—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 is sufficient for a low-complexity diagnostic tool: it explains what is returned, when to use it, and what an empty result means. Since there is no output schema, a bit more detail about the exact record shape could help, but the description covers the essential decision-making context.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The tool description adds context about when to use the tool but no additional parameter-level meaning, which fits the baseline of 3 for complete schema 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 names a specific resource (DOM mutations) and a precise temporal scope (since the last call), then lists the kinds of changes recorded: added, removed, or re-attributed, and where. This clearly differentiates it from static DOM inspection tools like dom_get_html or dom_query.

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 an explicit use case: call it after an action to determine whether the app re-rendered at all. It does not explicitly contrast it with sibling alternatives, but the contextual guidance is clear enough to tell the agent when this tool is the right choice.

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 full burden, and it largely delivers: 'List' clearly conveys a read-only diagnostic op, and the mention of 'JavaScript execution contexts' discloses that results cover more than DOM frames. Remaining gaps are edge behaviors — whether nested iframes are included, behavior with no attached tab, and whether results are live — but the core safety profile and return scope are accurately conveyed. No contradiction with annotations, since none exist.

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, each earning its place: the first states what it lists and where, the second gives the exact use case, cause, and follow-up action. The purpose is front-loaded before the guidance. No redundant phrasing, no restating of the tool name, no filler.

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

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

Given zero parameters, no output schema, and no annotations, the description covers everything needed to invoke it correctly: what it lists, where, when to call it, and what to do next (frame:'all' on dom_query). The return format is implied rather than stated explicitly, and edge cases (nested frames, no-tab error) go unaddressed — minor for a tool this simple, hence 4 rather than 5.

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 is empty (0 params), so the baseline is 4 and there is nothing to document. The description's second sentence (iframe diagnosis leading to frame:'all') indirectly explains why the tool takes no arguments — it operates on the already-attached tab. It adds useful context without needing to clarify any argument semantics, since none exist.

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

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

States a specific verb ('List'), a concre's resource ('frames and JavaScript execution contexts'), and a scope ('in the attached tab'), so an agent knows exactly what the tool returns. It further distinguishes itself from siblings like dom_query and debugger_evaluate_at_frame by framing itself as an inspection/discovery step rather than a query or evaluation. No tautology — the description adds real content beyond the name.

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

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

Gives an explicit trigger condition: 'Use it when a selector finds nothing.' It names the consequence and the alternative — content 'needs frame:'all' on dom_query' — so the agent knows both when to pick this tool and what to do with its results. This is explicit when/alternative guidance, not an implied hint.

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 for behavior, and it delivers: it explains computed style access on demand, iframe search with practical reasoning, and 'real visibility' as a distinct concept. It does not mention response limits, but the schema covers those details.

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, front-loaded with the core function and return data, and no wasted words. The second sentence adds actionable usage guidance efficiently.

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 eight parameters and no output schema, the description covers the most decision-critical behaviors: selector querying, return fields, computed styles, and iframe search. The schema fully documents the remaining parameters, so an agent has enough context to call this 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the rationale for frame:'all' in single-page apps and clarifying how the styles parameter should be used. This is extra guidance, not just restatement.

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

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

The description states a specific verb and resource: 'Query elements by CSS selector' and enumerates the rich set of returned data (tag, id, classes, text, attributes, geometry, visibility). This clearly separates it from sibling tools like dom_get_html or dom_list_frames, which have different scopes.

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 usage context, such as setting frame:'all' to search inside iframes and asking for computed styles by naming properties. It does not explicitly name alternatives or state when not to use this tool, but the guidance is strong enough to steer an agent effectively.

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 behavioral disclosure burden and does it well: it discloses that the tool checks visibility, that probe requires an extra round trip, and that session ownership may be absent '(if any)'. This gives the agent useful expectations beyond the bare 'list' verb.

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 with no filler: the first delivers the purpose and output fields, the second connects the result to the next step. Every clause adds value, and the most important information 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?

Given there is no output schema, the description compensates by listing the returned fields explicitly and explains how the index should be consumed. It does not describe output formatting or failure behavior, but for a simple listing tool the critical context is present.

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

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

Schema description coverage is 100%, so the input schema already documents host, port, and probe. The tool description does not add parameter details, but it also does not need to because the schema already carries that weight. Baseline 3 is appropriate.

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

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

The description opens with the specific verb 'List' and the resource 'debuggable tabs in Chrome', then enumerates the exact fields returned: index, title, URL, visible flag, and owning DevCDP session. This clearly distinguishes list_tabs from sibling tools like sessions_list or devtools_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?

The description gives clear context for when this tool is useful: when you need the list of tabs and their indices. It also provides direct downstream guidance by instructing the agent to use the index with target:'index:<n>' in devtools_connect. It does not explicitly name alternatives or exclusions, so it misses the top score.

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 full burden. It discloses that calls return short summaries by default, that full:true or id returns detailed entries, and that it is designed to be cheap. As a read tool, the behavior is clearly non-mutating. It doesn't discuss edge cases like empty results, but covers the main behavioral traits.

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, each earning its place: the first establishes purpose and return format, the second gives usage guidance. No filler or repetition of schema content.

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 adequately covers what the tool does, when to use it, and how to get detailed entries. It does not describe the structure of summaries or full entries, and there is no output schema, but the core semantics are clear for an agent to invoke and use the results effectively.

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

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

Schema description coverage is 100%%, so the schema already documents all parameters. The description adds a small amount of value by explaining that 'full:true or an id' reads entries in detail, which maps to the full and id parameters, but otherwise it does not go 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 a specific verb ('Look up') with a clear resource ('what previous sessions learned about this app — failures and the recovery that worked'). It distinguishes itself from sibling memory_record and memory_import_legacy by focusing on retrieval, and from docs_search by pointing to session-learned knowledge rather than general docs.

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 usage triggers: 'Search it whenever a step fails, before asking the user for help' and 'cheap to call at the start of a session'. It does not name alternatives or exclusions, but the guidance is actionable and enough for an agent to know when to invoke 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 the full burden of behavioral disclosure. It discloses that malformed entries are skipped and that this is a one-off operation. It does not explicitly state whether the import merges or overwrites existing store entries, but the core behavioral traits are conveyed.

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 tightly written sentences with no filler. The key operation and migration caveat are front-loaded, and every sentence contributes useful 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?

For a one-parameter tool with no output schema and no annotations, the description is largely complete: it states what the tool does, when to run it, and the important malformed-entry caveat. It could add return/error behavior or explicit merge vs overwrite semantics, but the tool's low complexity keeps this gap modest.

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 provides 100% coverage for the single path parameter and describes it as the full path to the old memorymanagement.md file. The description adds contextual color about v4 Markdown and legacy status, but no substantive 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 uses a specific verb and resource: it imports a v4 Markdown memory file into the current store. It also clearly marks the operation as a one-off migration, distinguishing it from sibling tools like memory_get or memory_record.

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 states explicit timing and lifecycle context: 'Run once after upgrading, then delete the old file.' It does not name alternative tools or when-not conditions, but the specialized migration framing makes the intended usage unambiguous.

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 carries the burden and does meaningfully disclose behavior: all four fields are required and validated, and a vague entry has a future cost ('it costs context on every future lookup'). It does not describe persistence details like the shared/local store distinction, but that is already covered in the schema, so the description adds useful behavioral context.

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 earn their place: purpose, when to call, and quality/validation guidance. Information is front-loaded with the core action first.

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 record/write tool with no annotations and no output schema, the description covers purpose, usage trigger, validation, and quality expectations. The sibling memory_get implies the retrieval path, but the description could have directly noted that the stored entry is later read via memory_get to tie the workflow together.

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 adds qualitative guidance beyond the schema by warning that 'a vague entry is worse than none,' which affects how an agent should fill failure, recovery, and pattern. This is meaningful extra parameter semantics.

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

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

The description clearly identifies the action ('Record'), the object ('a failure and the recovery that worked'), and the intended outcome ('so a later session can skip the dead end'). It is immediately distinguishable from sibling tools like memory_get and memory_import_legacy because it is the write/record 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?

It gives an explicit trigger condition: 'Call it after any user-assisted recovery or non-obvious workaround.' This tells an agent when to use it, but it does not explicitly contrast it with memory_get or state when not to use it, so it misses the top score.

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 of behavioral disclosure. It clearly states that the network buffer is emptied, describes the intended effect on future reads, and explicitly notes that the browser's own Network panel is unaffected. This is strong transparency for a zero-parameter utility.

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 tightly written sentences, with the core action front-loaded and the key clarification in the second sentence. Every word earns its place; there is 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?

For a zero-parameter tool with no output schema and no annotations, the description is fully sufficient. It explains what the tool does, why an agent would use it, and what it does not affect. 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 tool has no parameters, so the baseline is 4. The description adds useful context by explaining why no parameters are needed: the tool acts on the current network buffer as a whole. There is no parameter ambiguity to resolve.

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 ('Empty the network buffer') and distinguishes it from the browser's own Network panel, which prevents confusion. It is immediately obvious what this tool does and how it differs from related tools like network_get_requests or console_clear.

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 it: before taking an action, to ensure subsequent network reads only reflect that action. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough that an agent can infer the right context.

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?

Wit no annotations, the description carries the full disclosure burden and does so well: it reveals the capture-boundary limitation, explains that response bodies are excluded by default 'because they are large', and offers the reload remedy. The read-only nature is implied by 'List' with no hidden mutating effects. Minor omission: no statement about pagination/ordering behavior, though the schema covers offset semantics.

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

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

Four sentences, each earning its place: core purpose, filter modes, body-size caveat, and capture boundary with a remedy. The verb+resource is front-loaded in the first word. There is no filler and no redundant restatement of schema content.

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 read tool with 11 parameters and no output schema or annotations, the description covers purpose, returned fields, filter modes, and the key trap (capture start), so an agent can call it correctly without further research. It could add a pointer to network_get_response_body for full bodies, but include_bodies largely fills that role.

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%, putting the baseline at 3, but the description adds real value beyond the schema: it groups the filter dimensions ('Filter by URL substring, method, status or failures only') and explains the rationale for include_bodies being opt-in ('because they are large'), naming the parameter directly. That pushes it a step above baseline.

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

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

Opens with a specific verb and resource — 'List HTTP requests captured since attach' — and enumerates the returned fields (method, status, duration, size, initiator). The listing verb disambiguates it from siblings like network_clear, network_wait_for_request, and network_get_response_body, and the filter sentence adds further scope. Nothing ambiguous remains about what the tool 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 final sentence gives actionable context: 'Capture starts when DevCDP attaches, so requests from before that are not here — reload to see them.' This tells an agent why prior requests may be absent and how to remedy it. It does not explicitly name alternatives such as network_wait_for_request or state when-not-to-use this tool, so it stops 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?

No annotations are provided, so the description carries the behavioral disclosure burden, and it delivers the single most important non-obvious trait: Chrome discards bodies on navigation, so reads must happen before leaving the document. It does not describe error behavior when the body has already been discarded or the response format, but the core failure mode is proactively disclosed.

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 with zero filler: the first front-loads the purpose and resource, the second adds a high-value caveat. 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 simple follow-up read tool, the description covers purpose, id provenance, and the critical lifecycle constraint. Gaps are minor: there is no output schema and the description does not hint at the return format, and the schema marks all params optional while the description implies one id is needed — but neither gap is likely to cause a wrong call.

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%: requestId/request_id aliasing, the source of the id, and the max_body_bytes cap semantics are all documented in the schema. The description's reference to "from network_get_requests" mostly restates what the schema already says, so it adds minimal value beyond the schema; the baseline of 3 applies.

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

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

"Fetch the full response body for one requestId from network_get_requests" uses a specific verb and resource and names the upstream tool that produces the requestId. This cleanly distinguishes it from siblings such as network_get_requests (lists requests) and network_wait_for_request (waits for a request), so an agent can tell them apart without opening schemas.

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

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

The description gives clear when-to-use context: it is a follow-up to network_get_requests, and the warning "read them while the page is still on the same document" provides explicit timing guidance that prevents a common failure. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough that an agent will use it 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 no annotations, the description carries the full burden and delivers: event-driven/no polling, immediate return for pre-existing matches, and a timeout failure mode. This goes well beyond the schema details.

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

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

Three sentences, front-loaded with the core blocking behavior, then edge cases and failure mode. Every sentence adds value with no repetition 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?

Covers the wait mechanism, when to call, the already-completed case, and timeout failure. Although there is no output schema, the description clearly says it returns the matched request; the exact request structure is reasonably implied by the network tool family.

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 applies. The description reinforces url_filter and timeout_ms but does not add meaning for method or allow_existing beyond what the schema already documents.

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

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

States a specific operation: block until a matching network request completes, then return it. The 'Block until...' phrasing clearly distinguishes it from sibling list/get tools like network_get_requests and network_get_response_body.

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 call timing ('immediately AFTER triggering the action') and covers the edge case of an already-completed request. It does not name alternative tools for non-wait scenarios, so it lacks explicit exclusions, but 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the visible effect (a status line in the badge) and highlights an important trait: this is the only channel the user actually sees. It also gives a style constraint ('Keep it to a few words'), which helps agents use it appropriately. It doesn't mention return/blocking behavior, but for this simple notification tool that is a minor omission.

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 filler. The first sentence states the core function, the second gives timing and rationale, and the third gives a constraint. Information is front-loaded and 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?

For a tool with 2 parameters, full schema coverage, no output schema, and no annotations, the description provides everything an agent needs to invoke it correctly: what it does, when to use it, and how to phrase the content. It is complete for its intended 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?

Schema description coverage is 100%, so the baseline is 3. The description adds stylistic guidance ('Keep it to a few words') that applies to the 'detail' parameter, but the individual parameter meanings are already fully covered by the schema ('What you are doing' and 'Short human-readable detail'). The description does not need to add more.

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

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

The description states a specific verb ('Show'), a specific resource ('a short status line ... in the badge'), and a clear audience ('the human'). It also distinguishes itself as the only visible user channel, which separates it from other session/communication tools like session_ask_user.

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 guidance on when to use the tool: 'call it before a slow or surprising step so a frozen-looking app is explained.' It explains the context and benefits clearly. It does not explicitly name alternatives or when not to use it, but the usage context is strong enough to guide an 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?

With no annotations, the description carries full burden. It clearly discloses the side effect profile: 'The page keeps its DOM and state; only the in-flight script is killed.' It also explains why the main thread cannot process navigation, adding important behavioral context beyond the basic action.

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 well-organized sentences: action first, trigger second, consequence and why nothing else works third. Every sentence earns its place, with no repetition 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 tool with no output schema and no annotations, the description fully equips an agent: it states what the tool does, when to invoke it, what happens to the page, and why alternatives won't work. 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 tool takes zero parameters, so no parameter semantics need to be explained. The empty schema covers everything; a baseline of 4 is appropriate because there is nothing parameter-related for the description to add.

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

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

The description states a specific verb and resource: 'Abort the JavaScript the page is currently running.' It also explicitly distinguishes itself from page_navigate and page_reload by explaining that they do not free a blocked thread, making the tool's unique role clear.

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

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

It gives an explicit trigger condition: 'Use it when a tool reports PAGE_UNRESPONSIVE.' It also names alternatives that should not be chosen (reloading, navigating) and explains why they fail, leaving no ambiguity about when to use this tool.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden, and it does so well by revealing the non-blocking return semantics. It honestly warns that the page may still be loading and tells the agent how to handle that. It could additionally mention failure modes like invalid URLs or blocked navigations, but the key behavioral trait is 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?

Two sentences with no filler. The core action is front-loaded, and the second sentence earns its place by providing essential asynchronous behavior and actionable follow-up guidance.

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 one-parameter navigation tool with no output schema, the description covers what it does and what to do after calling it. No essential operational detail is missing; the async caveat is exactly the kind of context an agent needs.

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 fully documents the single parameter as 'Absolute URL to open' with 100% coverage, so the baseline is 3. The description does not materially extend the parameter semantics beyond saying the navigation target is a URL.

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

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

States a specific verb ('Navigate'), a resource ('the attached tab'), and the target ('a URL'), making the tool's function immediately identifiable. It is clearly distinct from sibling page_reload, which reloads the current page rather than navigating to a new URL.

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

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

Explicitly describes the timing behavior—returns when navigation is committed, not when loading finishes—and gives concrete alternatives for waiting: network_wait_for_request for requests, or Playwright text waits before asserting. This gives the agent clear guidance on when and how to follow up, exceeding a bare nav command.

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 behavioral disclosure burden. It explains a non-obvious trait: reloading replays console and network activity under DevCDP observation, recovering data unavailable from before the attach. It could more explicitly warn about page state loss, but the reload semantics largely imply it.

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 filler. The primary action is front-loaded, and the explanatory context about post-attach reloading is directly relevant and 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 simple one-parameter tool with no output schema, the description provides sufficient context: what it reloads, why it is useful right after attaching, and what benefit the agent gains. Nothing critical 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 input schema fully describes the only parameter (bypass_cache) with a clear description and default, so the schema already carries the parameter meaning. The description adds no extra parameter detail, which is acceptable at 100% schema 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 verb ('reload') and resource ('attached tab'), making the tool's action unambiguous. It also distinguishes itself from page_navigate by targeting the current attached tab rather than navigating elsewhere.

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 when-to-use context: right after attaching, because pre-attach console history and network traffic cannot be recovered. It does not explicitly name alternatives or exclusions, but the use case is clearly scoped 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the useful non-aborting per-entry failure behavior, but doesn't mention that expressions may execute arbitrary code with side effects or how promise results are serialized. This is partial transparency only.

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 concise sentences, each earning its place: the core operation, the motivating use case, and the failure model. The most important behavioral distinction 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 two-parameter tool with no output schema, the description gives the essential contract: a map of name to result and per-entry failure handling. It could mention evaluation context or value serialization, but those are minor gaps for an agent selecting and invoking 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?

The input schema already describes both parameters and has 100% coverage. The description's 'named expressions' mirrors the `{ name, expression }` structure but adds no meaningful detail about `await_promise` or expression evaluation semantics. Baseline 3 is appropriate.

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

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

The description names a specific operation — evaluate several named expressions — and explicitly promises a name-to-result map. It distinguishes itself from single-expression evaluation tools by emphasizing the batch, single-round-trip behavior.

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

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

It gives a clear use case: sample a lot of app state at once instead of paying a round trip per question. It doesn't explicitly name an alternative like console_evaluate or state when not to use it, but the intended context is well defined.

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 of disclosing behavioral traits, and it does so strongly. It reveals the non-blocking nature ('Returns immediately'), the required polling follow-up, the on-page badge UI, and the need to relay the instruction in the reply. These are behaviors not inferable from the schema and essential for correct usage.

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: the first states purpose and UI, the second conveys async behavior and polling target, and the third mandates relay behavior. Information is front-loaded, with the core ask in the first sentence and no redundant or filler content.

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 fully adequate for a two-parameter tool: parameters are fully documented by the schema, and the description explains the async outcome pattern, the badge UI, and the agent-side relay requirement. It covers everything an agent needs to invoke the tool correctly and handle the follow-up step, despite the absence of an output schema.

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 'confirmation button' which aligns with the wait_for enum's 'confirmation' option and 'instruction' schema text already states 'Exactly what the person should do, in one sentence.' The description does not add meaningful parameter-level detail beyond what the schema already provides.

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

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

The description begins with a specific verb-resource pair: 'Ask the human to do something in the browser,' and further distinguishes it from notification tools by specifying it 'show[s] the request in the on-page badge with a confirmation button.' This makes the tool's unique role clear and differentiates it from sibling tools like notify_user and session_poll_user_action.

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 use: it is for asking a human to act in the browser and uses a badge with a confirmation button. It also gives explicit follow-up guidance: 'Returns immediately — poll session_poll_user_action for the outcome' and instructs the agent to relay the instruction in the reply. However, it does not explicitly state when not to use this tool or mention an alternative such as notify_user, so it stops short of a full 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It usefully clarifies that session_end does NOT detach the tab or clear breakpoints, and notes that a summary is returned. However, it does not disclose whether the session becomes unusable after closing, whether it is irreversible, or what the summary contains.

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

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

Two short sentences with no wasted words. The primary action is front-loaded, and the important non-detach caveat plus the alternative tool are provided in the second sentence.

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 tool with no output schema, the description is complete: it explains the action, the return value, and the key behavioral boundary (does not detach), and directs the agent to the correct sibling when a different outcome is needed.

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 the schema is fully covered at 100%, so there is nothing for the description to explain. The baseline for zero-parameter tools is 4, and the description adds no conflicting or confusing 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 states a specific verb ('Close'), resource ('session'), and expected outcome ('return a summary'). It also differentiates from the sibling devtools_disconnect by explicitly saying it does not detach, so the agent can tell the two apart immediately.

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 usage context: call session_end to close a session and get a summary, and use devtools_disconnect instead when done with the browser entirely. This is an explicit when-to-use versus when-not-to-use contrast with the relevant 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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It transparently explains that the tool returns a chronological timeline of mixed event types and names those types. It does not mention retention limits or response format details, but for a read-only history retrieval tool this is reasonable.

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 first sentence defines the tool's scope and output, and the second states the intended use case. Both sentences earn their place, and the key information 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 optional-parameter retrieval tool with a rich sibling set, the description is mostly complete: it names the returned content, ordering, and use case. It could add a bit more about the return entry structure, but the absence of an output schema is not critical when the semantics are clear from the name and supporting schema.

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 parameters need no elaboration in the description. The description adds contextual meaning about what the timeline contains but does not need to explain limit, since, or types because the schema already covers them adequately.

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, useful purpose: a unified, ordered timeline of session activity including specific event categories. It clearly distinguishes itself from focused siblings like console_get_logs or network_get_requests by emphasizing breadth and chronological ordering.

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 advises using this tool to reconstruct what happened when a step behaved unexpectedly, which gives clear contextual guidance. It does not mention when to prefer the more specialized sibling tools, but the primary use case is clear enough for correct selection.

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

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

With no annotations, the description carries the full burden. It discloses a genuinely non-obvious behavior: the tool is cursor-based and stateful ('Pass the cursors back on the next call to get only what is new'), enabling incremental polling, and 'snapshot' implies a non-destructive read. However, it does not disclose whether an active session is required, what happens without one, or how the response/cursors are structured, and there is no output schema to cover that gap.

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

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

Three sentences, front-loaded with the core purpose first, then the cursor protocol, then the cost-based usage rationale. Every sentence earns its place; the 'cheapest' claim doubles as usage guidance rather than 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 no annotations and no output schema, the description carries a heavy burden and it covers the core concept, the incremental pattern, and the efficiency rationale. It leaves gaps: whether an active session is a prerequisite, the shape of the returned snapshot (where cursors appear), and explicit naming of the three per-channel alternatives. Sufficient for a safe first call, but not complete guidance.

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 and the schema already documents all six parameters. The description adds modest connective meaning by explaining the incremental pattern behind the cursor parameters, though it does not re-explain individual fields. Minor friction: the description says 'the cursors' (plural) while the schema exposes only log_cursor as an input.

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 and resource: it produces 'one snapshot of console output, network requests and DOM mutations together'. It distinguishes itself from siblings by explicitly offering the combined view 'instead of three separate calls', which maps to console_get_logs, network_get_requests and dom_get_mutations in the sibling list, so an agent can tell this tool apart without opening schemas.

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

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

The description gives clear usage context: use this to observe 'the effect of an action' and because it is 'the cheapest way' compared to making three separate calls. The cursor sentence further defines the expected call pattern for successive retrieval. It stops short of explicit when-not guidance, such as preferring console_get_logs/network_get_requests/dom_get_mutations when only a single channel is needed.

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 burden of showing this is a read-only inspection: 'Where the session plan stands' conveys a status query rather than a mutation. However, it does not explicitly state that it has no side effects, nor what happens when no session exists or a handover is pending.

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?

A single sentence phrases each piece of returned information compactly. The core meaning, 'where the session plan stands', 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 zero-parameter status getter with no output schema, the description adequately enumerates the expected return content: goal, per-step status, current step, and outstanding handover. It is not exhaustive about edge cases or relation to session_get_state, but it is sufficient for a basic call.

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

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

The tool takes zero parameters, so the description does not need to detail arguments. The absence of an input schema is therefore not a 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 identifies the tool as a status read for the session plan and lists the specific data returned: goal, step statuses, current step, and human-handover flag. It distinguishes this from generic session tools by focusing on the plan's step-level state, though it uses a noun phrase rather than a verb and does not explicitly contrast with session_get_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?

No guidance is given about when to call this tool versus session_get_state, session_get_activity, or sessions_list. The description implies a status-check use case but provides no exclusions, prerequisites, or alternative routing.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses that sensitive fields are redacted, values are only captured during handover/takeover, and unprompted actions are still readable. It does not state side-effect characteristics, but the 'get' semantics and history focus make those less critical.

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

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

Four short sentences, no fluff, and each sentence carries valuable context: what is returned, unprompted availability, cursor pagination, capture timing, and redaction. The most important statement 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?

With no output schema and no annotations, the description covers the essential contract: action kinds, element association, redaction, and cursor-based pagination. It does not spell out exact response fields, but for a read-only history getter the description provides enough detail for an agent to select and call it correctly.

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

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

All three parameters already have clear descriptions in the schema: kinds examples, limit constraints, and cursor behavior. The description adds conceptual context like 'typed values, chosen options' and cursor-as-new-only, but it mostly reinforces what the schema already communicates, so no strong bump above baseline.

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

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

Description states exactly what the tool returns: user actions in the browser (clicks, typed values, chosen options, submissions) and the element each action touched. It also distinguishes itself from sibling tools by noting it works whether or not it was prompted, making it readable even for unprompted help.

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?

Description gives clear usage context: use this when you need to see what the human did, even if you didn't explicitly ask. It also explains cursor usage for incremental reads. It does not name alternative sibling tools explicitly, but the unprompted work note is strong enough 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?

With no annotations, the description must carry the behavioral disclosure burden. It does reveal the key return behavior ('Returns acted:false while waiting') and advises against tight-loop polling. However, it does not describe what a successful completion response looks like, whether the call blocks or returns immediately, or any error or timeout behavior, leaving some important behavioral context unspecified.

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 concise sentences with no filler. It front-loads the core purpose, then delivers return behavior and polling guidance in an efficient, scannable format. 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?

For a simple, zero-parameter polling tool with no output schema, the description covers the essential operational context: what it checks, what acted:false means, and how often to call it. It does not specify the full return shape or how to retrieve the actual action results, but the tool is simple enough that 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 zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter details, and the baseline of 4 for a no-parameter tool is appropriate.

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

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

The description states a specific action—check whether the human has completed what session_ask_user requested—and clearly identifies the resource being polled. It distinguishes itself from the related ask_user workflow by focusing on the poll-for-completion role, making its purpose immediately understandable.

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 this tool: after session_ask_user has been called, to check human completion. It also provides explicit cadence guidance ('a few seconds apart rather than in a tight loop'), but it does not explicitly mention alternatives or when not to use it, such as using session_get_user_actions to retrieve the actual action details.

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 annotations, so the description carries the behavioral disclosure burden. It indicates a read-only listing operation via 'Show', scopes results to currently running sessions on this machine, and links results to diagnostic uses. However, it does not explicitly state side effects, data freshness, or structural behavior beyond listing.

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 filler. The first sentence states what the tool does, and the second gives practical guidance, both earning their 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 listing tool with no output schema, the description provides a complete enough picture: what is returned (sessions and tabs) and when to use it. It does not detail the exact response shape, but that is less critical given the simplicity of the operation.

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?

This tool has zero parameters, so there is no schema burden. The description still clarifies what the returned data represents (sessions and their tabs), which is useful despite the empty input 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 a specific verb ('Show') and resource ('every DevCDP session currently running on this machine and the tabs each one holds'), making the tool's scope immediately clear. It also differentiates itself from sibling tools like list_tabs by emphasizing the all-sessions-on-machine view rather than a single 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?

The description explicitly provides two concrete use cases: understanding why a tab is unavailable and confirming whether two agents are fighting over the same page. It does not mention when not to use the tool or name alternative sibling tools, but the context is clear enough for an agent to select it appropriately.

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 annotations, so the description carries the full disclosure burden. It clearly discloses that calling this tool opens a tracked session and that failed steps can fall back to asking the human. It does not mention whether an existing session is replaced or what the function returns, but the main stateful behavior is transparent.

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 filler: one defines what the tool does, and the other gives the usage boundary. It is well structured 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?

For a session-start tool with two required parameters, the description sufficiently explains its purpose, inputs, and applicability. The main omission is return-value or reentry behavior, but the schema and sibling session tools provide enough surrounding context.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description adds only the framing that steps are ordered, which reinforces rather than extends the schema. This matches the baseline 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 states a specific action and resource: 'Open a debugging session with a goal and an ordered list of steps.' It also distinguishes the tool from lighter-weight investigations by explaining that it tracks progress and supports fallback to asking the human.

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

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

Explicit usage guidance is present: 'Use it for multi-step reproductions; a single-question investigation does not need it.' This clearly tells the agent when to invoke the tool and when to skip 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?

由于无注释，描述承担了行为揭示的全部责任。这是正面的：它陈述了这是一项修改性的状态推进操作（'Mark...complete'、'advance'），并给出了结果状语。但该描述未提及其他的副作用（例如，该操作不可逆吗？原本的步骤是否被永久覆盖？）也没有透露状态型或会话层的前置条件（例如，是否需要同步存在 session_start 或当前步骤）。它具有一定的透明度，但有所保留。

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?

该描述由两句话构成，恰当紧凑，且功能说明被优先放置。不存在冗余：它将动作（标记完成并推进）、参数的角色（附带你的发现），以及返回值（下一步或 allDone）都包含其中，而没有一句冗余。

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?

对于只带一个参数且无输出模式的工具，描述覆盖了主要的调用语义：何时使用该工具以及返回内容。然而它遗漏了关键前置条件——未说明需要一个活动会话或已存在当前步骤——且'next step'的具体形式（如步骤ID、步骤对象或文本）并未被定义，使得返回值在一定程度上是不确定的。它足以支撑基本调用，但不足以支撑完整理解。

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?

输入模式的描述覆盖率为100%，并且模式中已经将'result'参数刻画为'What this step established — a real observed value, not a guess.' 该描述只是以'with what you found'重新复述了这一概念，并未增加任何语义。它还留下了一些隐式的不一致：描述强调要提供一个 result，但模式中该参数却是可选的（required:0）。该项信息停留在原有模式内容层面上。

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?

该描述使用明确的动词、资源和作用对象：'Mark the current step complete' 和 'advance'，并说明了返回行为（下一步或 allDone）。这对工具的核心功能给出了清晰定义，但它并未提名任何兄弟工具来辅助区分（例如 session_step_failed），因此以4分被扣留。

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?

该描述隐含了使用场景：当代理已成功完成某一步，并开启后续步骤时。它隐含地将'完成'与失败的操作相对照（如 session_step_failed），但从未明确说明备选方案何时适用，也未列出任何前置条件（例如，必须当前有一步正在进行）。该指引是推断性的，而非显式。

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 behavioral burden. It discloses useful behavior: checks memory for a known recovery first, then tells the agent how to hand over to the human. It does not fully explain side effects like whether a failure is recorded, but the disclosed flow is meaningful.

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 concise sentences, each earning its place: purpose, behavior, and usage context. The primary action is front-loaded and no redundant detail is included.

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 one-parameter tool with full schema coverage and no output schema, the description is complete. It covers purpose, underlying behavior, when to use it, and realistic examples, giving an agent enough context to select and invoke it correctly.

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

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

Schema description coverage is 100% and the single 'reason' parameter is already documented as 'Why the step could not be completed.' The description adds no additional parameter semantics, so the 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?

States a specific verb and resource: 'Report that you cannot complete the current step yourself.' It clearly distinguishes the tool from siblings like session_step_done by emphasizing the inability to complete the step and the handover to a human.

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 an explicit use case: 'Use it for anything automation genuinely cannot do' with concrete examples. It implies when not to use it (automation can do the step), but does not explicitly name alternatives 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the fallback to the loaded script when no source map is available and the guarantee that the caller is told which of the two was returned, preventing confusion between bundle and original lines. This is meaningful behavioral context beyond a bare 'read' statement, though it does not touch on other traits like error handling or permissions.

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 with no wasted words. The primary action is front-loaded, and the second sentence adds valuable fallback and disambiguation behavior in a compact way. Every phrase 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 there is no output schema, the description usefully hints at the response by explaining that the tool always indicates which of the two sources (original vs loaded) was returned. Combined with the schema's full parameter documentation, an agent has enough to invoke the tool correctly and interpret the result. Minor gaps like exact return structure or error behavior exist, but they are not critical for calling 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?

The input schema already documents all three parameters with descriptions, so schema coverage is 100%. The description does not add extra meaning to path, start_line, or end_line beyond what the schema states, so the baseline of 3 applies. No parameter information is missing that the description needs to compensate for.

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 ('Read') and a specific resource ('original pre-bundling source file via the page's source maps'), clearly distinguishing it from siblings like source_get_script, which presumably returns the loaded script. The fallback clause further reinforces the difference between original and bundle content. An agent can tell this tool apart from neighboring source tools without opening their schemas.

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

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

The description implies when to use this tool: when you need the original pre-bundling source rather than the loaded script. However, it does not explicitly name alternative tools or state when not to use it, leaving the routing decision partly to inference. The fallback note is behavioral context rather than a direct usage guideline.

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 burden, and it adds meaningful behavioral detail: it reads the 'actually loaded' source (not the file), and returned lines are numbered consistently with breakpoint quoting. This is enough for a simple read 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?

Two focused sentences that front-load the core purpose and the most important behavioral guarantee (line numbers match breakpoints). Every clause earns its place with no redundancy.

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

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

For a read-only, 4-optional-parameter tool with no output schema, the description covers selection, line range, and return-values behavior concisely. It could additionally clarify behavior when both script_id and url are provided, and what happens with no matches, but nothing essential is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description broadly maps scriptId/URL substring/line range to the parameters, but adds only minimal semantic value beyond the schema's existing per-parameter 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?

States a precise verb ('Read'), the resource ('source Chrome actually loaded'), and the selection methods (scriptId or URL substring, optional line range). This clearly separates it from sibling tools like source_list_scripts and source_get_file.

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

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

Gives clear context for when to use the tool: to read the actual loaded script source rather than what's on disk, and you can identify it by scriptId or URL. It does not explicitly name alternatives or exclusion cases, but the usage scenario is unambiguous.

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 burden. It discloses that listed files are 'recoverable from source maps' and represent the 'pre-bundling file tree', which sets expectations about scope. But it does not mention behavior when source maps are absent, ordering, or whether all recoverable files are included.

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 with no fluff. The first defines the operation and the second supplies the usage context. Both sentences earn their place and the key information 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 list tool with two optional, well-documented parameters and no output schema, the description covers purpose, scope, and use-case. It could be more explicit about return format or handling of missing source maps, but nothing critical is missing.

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

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

Schema coverage is 100% and the schema descriptions for limit and filter are already clear ('Maximum paths to return', 'Only paths containing this substring'). The tool description adds no additional parameter meaning, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'List the original source files recoverable from the page's source maps — the pre-bundling file tree.' It clearly differentiates this from sibling tools by framing it as a discovery step before source_get_file or setting a breakpoint, so an agent knows its role immediately.

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 second sentence gives explicit guidance: 'Use it to discover real file paths before calling source_get_file or setting a breakpoint on an original file.' This states when to use the tool and positions it relative to downstream actions, though it does not name alternatives it is better than.

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 behavioral disclosure burden. It discloses that the index is captured when DevCDP attaches, which is a meaningful timing trait, and it correctly implies a read-only listing operation. It could add more about whether the list updates dynamically, but the provided timing context is a solid addition.

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 concise sentences with no fluff. The core action and return info come first, then the timing nuance, then a practical usage pointer. 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 is simple, has no required parameters, and the description covers what is listed and why. Since there is no output schema, the description's mention of size and source map helps fill the return-value gap. Missing details like dynamic runtime script inclusion are minor for this use case.

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

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

Schema coverage is 100% and the schema already documents limit, filter, and with_source_maps. The description adds a small behavioral clue for filter ('URL substring') and application context, but it does not materially expand 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 clearly states the tool lists JavaScript files loaded in the page and specifies what information is returned (size, source map presence). It is specific enough to distinguish it from broad debugger or navigation tools, though it does not explicitly differentiate it from sibling source_list_files or source_get_script.

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 useful context for when to use it—before setting a breakpoint, and notes it works on already-open pages. However, it does not mention alternatives or any conditions where another tool should be used instead, so usage guidance is implied rather than 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?

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that search covers both loaded scripts and source-map-recoverable original files, and specifies the return shape: file, 1-based line, and matching line. It does not discuss regex failure modes or result limits in prose, but the read-only nature is clear and the schema covers result-limiting parameters.

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 tightly written sentences: the first conveys action and scope, the second gives the use case and return values. Every sentence earns its place, and the most important operational detail (search scope) 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 search tool with fully documented parameters, the description supplies the missing context: the intended use case, the source scope, and the output. Even without an output schema or annotations, an agent has enough information to decide when to invoke it and what to expect back.

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 and the description does not need to repeat parameter details. It adds only minor semantic reinforcement by mentioning that the query can be a string or regular expression, which is already reflected in the schema.

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

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

The description names a specific verb ('Search'), the exact resource ('text of every loaded script...and every original file recoverable from source maps'), and the accepted input ('string or regular expression'). It clearly differentiates this search tool from sibling list/get source tools by emphasizing discovery when the file is unknown.

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

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

The description explicitly states when to use this tool: 'fastest way to locate a handler when you know a function name, a message or a field name but not the file.' It implies alternatives like source_get_script or source_get_file when the file is known, though it does not name them explicitly or list exclusions.

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