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

Annotations already declare readOnly, idempotent, open-world, and non-destructive behavior, so the description only needs to add behavioral context beyond that. It adds the retention window ('since it was first inspected'), the inclusion of uncaught exceptions, and the practical insight that console errors may not be visible on screen. No contradiction with annotations.

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

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

Two sentences with no filler. The core behavior is front-loaded in the first sentence, and the second sentence provides a concise, valuable usage rationale without 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?

Despite having no output schema, the description explains the return content (console output and uncaught exceptions) and the retrieval window. Annotations cover safety and idempotency, and the schema covers parameters, so an agent has enough to select and 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?

Schema description coverage is 100%, and both parameters (target_id and limit) are already clearly documented in the schema. The description does not add additional parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description names a specific verb ('Return') and resource ('recent console output and uncaught exceptions captured from the target'), which clearly distinguishes it from visual/DOM tools like screenshot and dom_snapshot. It also adds a meaningful temporal scope ('since it was first inspected').

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

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

The description gives clear context for when to use the tool: 'The fastest way to see why something failed — errors that never appear on screen.' This implies it is preferred for diagnosing failures not visible in screenshots or DOM snapshots, though it does not explicitly name sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds that it returns rendered HTML (not just raw DOM) and that it is exact, which is useful context beyond the annotations. No contradiction.

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 core purpose, and provides a clear rationale for using it over screenshots. Slightly verbose in the second sentence but efficiently sized for the tool's importance.

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

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

Given the tool is simple (2 params, no output schema, no nested objects), the description is complete enough: it explains the scope via selector, the target via target_id, and the behavioral advantage over screenshots. The exact return format is not specified, but for a read-only snapshot tool this is not a major 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?

Schema description coverage is 100%, so both parameters are already well-documented (selector and target_id with descriptions). The description adds the semantic meaning of selector as scoping the snapshot, but the schema already states that. No additional semantics beyond the schema, so 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 clearly states the tool returns rendered HTML for a target, with options for the whole document or a subtree via CSS selector. It distinguishes itself from screenshot and query_dom by explicitly positioning this as the exact, information-rich alternative to screenshots.

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 tells when to use the tool (when the agent needs to read the DOM rather than a screenshot) and contrasts with screenshots, but does not explicitly mention when not to use it or alternatives like query_dom for specific queries. Still, the context of preferring it over screenshots 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds concrete return fields and positions the tool as the necessary first lookup, which goes beyond the annotation metadata. No contradictions.

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

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

Two efficient sentences: the first gives the resource and output, the second gives workflow guidance. Front-loaded, no filler, 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?

Even though there is no output schema, the description explicitly names the fields returned and explains why the tool matters. For a parameterless list operation, this is complete and self-sufficient.

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

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

The tool has zero parameters, so there is no argument semantics to clarify. The schema coverage is trivially 100%, and the description appropriately focuses on the output shape rather than non-existent inputs.

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 ('List'), the resource ('debuggable targets on the DevTools endpoint'), and enumerates the target categories and returned fields (id, type, title, URL). It is immediately distinguishable from sibling tools like screenshot or console_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 explicitly instructs the agent to 'Start here' and explains that the returned target id is what every other tool needs, providing a clear workflow directive. It doesn't mention when not to use it, but for a listing tool that is not a significant gap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it states that headers are never captured and sensitive URL query values are redacted, which are important privacy/behavioral traits an agent needs to know. It does not describe pagination or exact return format, but the output schema is absent and the description covers the key behavioral constraints.

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

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

The description is a single, dense sentence that front-loads the core purpose and then adds two important constraints (no headers, redacted query values). Every word earns its place; 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 read-only, idempotent list tool with 100% schema coverage and no output schema, the description is largely complete. It explains what is returned, what is excluded, and what is redacted. The only minor gap is that it doesn't describe the exact response structure or ordering, but given the tool's simplicity and the annotations covering safety, this is acceptable.

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 three parameters (limit, target_id, url_filter) with descriptions. The tool description adds no additional parameter-level meaning 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?

The description clearly states the tool returns recent network requests with specific fields (method, URL, status, MIME type, failures), and explicitly distinguishes it from siblings by noting what it does not capture (headers) and what is redacted (sensitive URL query values). This makes it easy for an agent to understand the tool's purpose and scope.

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

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

The description implies when to use this tool: when network request details are needed, and it clarifies exclusions (headers never captured, sensitive query values redacted). It does not explicitly name alternative sibling tools or state when not to use it, but the context signals and sibling list (screenshot, list_targets, dom_snapshot, query_dom, console_logs) make the use case reasonably 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 readOnlyHint and idempotentHint already true in annotations, the safety profile is covered. The description adds useful behavioral context beyond annotations by revealing the output shape (outer HTML), the capped result set, and the real-time page verification purpose, which helps an agent predict call outcomes.

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 primary action and cap are front-loaded, and the second sentence adds concrete use cases. Every phrase earns its place without redundancy.

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

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

For a low-complexity read-only tool with three fully documented parameters and no output schema, the description adequately explains the return value (outer HTML of matches) and the practical purpose. Nothing an agent needs to decide whether to call this tool is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it mentions 'CSS selector' and 'capped' but does not elaborate on parameter formats or defaults, all of which 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 opens with the specific verb and resource: 'Return the outer HTML of every element matching a CSS selector (capped).' It differentiates itself from siblings like dom_snapshot by specifying targeted selector-based querying with capped results, and it states the practical purpose of locating elements to click or type into.

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

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

The description provides clear usage context: 'Use to locate the exact elements to click or type into, and to confirm what is actually on the page.' It does not explicitly name alternatives or state when not to use it, so it misses the top exclusions criterion, but the intended scenarios are 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?

Annotations already establish the operation is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond the annotations: the output is a PNG and the scope is the target's viewport. It does not mention rate limits or return mechanics, but these are not critical given the annotation coverage.

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 communicate the core behavior, output format, and usage guidance without any filler. The most important action 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?

With one well-documented parameter, complete annotations, and clear guidance contrasting it with a sibling, the description fully supports correct invocation. No output schema exists, but the PNG screenshot behavior is clearly stated, so an agent knows what to expect.

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 single parameter target_id is fully documented in the schema, so the description does not need to add parameter details. The description adds no additional semantic meaning beyond what the schema already provides, making the baseline 3 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 and resource: 'Capture a PNG screenshot of the target's viewport.' It also distinguishes the tool from dom_snapshot by stating it is for visual layout, rendering, and image checks rather than content reading.

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 prefer dom_snapshot for reading content and to use this tool for visual layout, rendering, and image checks. This directly tells an agent when to choose it over a named sibling tool.

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