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

No annotations provided, so description fully bears the burden. It reveals use of CDP Input.dispatch commands, spatial validation for click, auto-clear for type, and the temporal awareness of waitFor. Does not mention error handling or rate limits, but overall 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?

Well-structured with sections for actions, locators, and important notes. Front-loaded with core concept. Some verbosity in action list but still efficient for the complexity.

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

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

Given the tool's high complexity (18 params, nested objects, no output schema), the description is remarkably thorough. Covers all actions, locators, waitFor, and edge cases. Provides sufficient context for agent decision-making.

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 baseline is 3. The description adds value by explaining locator strategies, providing waitFor examples, detailing offset use, and clarifying action-specific parameters 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 it is 'THE PRIMARY INTERACTION TOOL' that combines element location and action into a single tick. It lists all actions and locator strategies, distinguishing it from sibling tools like coordinate_click and get_semantic_surface.

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 guidance to prefer backendNodeId over coordinates, and explains use cases for coordinate (Canvas/WebGL). Also describes when to use each action. Does not explicitly contrast with all sibling tools but gives clear 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?

The description discloses key behavioral traits: it scans the whole run (not just last action), categorizes failures with specific labels, and surfaces the earliest with causal explanation. No annotations are provided, so the description carries the full burden; it does a good job but doesn't explicitly state whether the tool is read-only or has side effects.

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

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

The description is front-loaded with 'FIRST POINT OF FAILURE' and each sentence adds value: scope, categories, causal explanation, session context. It could be slightly more concise but is not overly verbose.

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 explains the tool's behavior and context (loaded or live session), but without an output schema, it lacks explicit detail about the return format (e.g., a list of errors, an object with the first failure). This leaves some ambiguity for an AI 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 input schema has no parameters, and schema description coverage is 100% (0 of 0 params documented). Per guidelines, baseline is 4 when there are 0 parameters, and the description adds no param info because none 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?

Description clearly states the tool scans the entire recorded run for failures, labels them with error categories, and surfaces the earliest one with a causal explanation. This distinctively separates it from sibling tools like browser_verify (which checks live state) or browser_explain_last_action (focuses on last action only).

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 positions this as the 'FIRST POINT OF FAILURE' and explains it operates on a loaded past session or live session. This implies it's the go-to for diagnosing failures after a run, but doesn't explicitly mention when to avoid using it or direct alternatives among siblings.

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

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

No annotations exist, but description discloses behavior: returns state booleans, supports cross-iframe via backendNodeId, and polling with timeoutMs. It does not mention side effects, but the tool is read-only in nature.

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 short paragraphs front-load purpose, then usage, then additional features. Every sentence adds value 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 state assertion tool with no output schema, the description lists all return fields. It covers parameters and usage guidance adequately, making it self-contained.

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

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

Schema coverage is 100%, but description adds meaningful context: explains timeoutMs for polling, backendNodeId for cross-iframe, and outcome fields. This goes beyond the bare 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's purpose: 'Assert the state of a specific element without pulling the full semantic surface.' It lists return fields, distinguishing it from broader tools like get_semantic_surface or get_element_tree.

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 advises to use for 'quick state checks on known elements after an action, rather than re-fetching the entire page.' This provides clear when-to-use context and implies 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?

No annotations provided, but description fully discloses behavior: records human actions with provenance, captures flight recorder data, enables subsequent timeline tools. Also mentions requirement for visible session and completion methods.

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?

Description is somewhat lengthy but well-organized with clear sections. All sentences add value. Could be slightly more concise but front-loads purpose effectively.

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 output schema and a simple parameter, the description fully covers the handoff process, what happens to human actions, and how to end the handoff. No missing context for an agent to use 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% for the single 'note' parameter. Description does not add meaning beyond schema; it only restates that the note is recorded on the timeline. 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?

Explicitly states 'HUMAN HANDOFF' and describes pausing agent automation to let a human reproduce behavior. Differentiates from sibling tools like browser_end_handoff by framing the start of the handoff workflow.

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

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

Provides clear context for when to use (agent cannot reproduce behavior) and steps to follow after calling. Does not explicitly exclude alternative tools but implies this is for failure recovery.

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 bears full responsibility. It discloses that the session is closed, resources released, and active screencast/recording stopped. This covers key behavioral traits, though it could mention if the action is irreversible or if there are confirmations.

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 action, no redundant information. Every word contributes value.

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

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

For a simple tool with no parameters and no output schema, the description is sufficient. It covers the primary action and additional effects (stops screencast/recording). Minor gap: doesn't mention if it also closes all tabs or if it's part of a lifecycle (e.g., must be preceded by browser_launch).

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

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

There are no parameters (0 params, 100% schema coverage). Per guidelines, baseline is 4. The description doesn't need to add parameter meaning.

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

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

The description clearly states the verb ('Close'), the resource ('active browser session'), and the action ('release all resources'). It distinguishes from siblings like browser_close_tab, browser_launch, and browser_stop_recording by specifying it affects the entire session and stops screencast/recording.

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 (end session), but lacks explicit when-not-to-use or alternative tools. For example, it doesn't mention that browser_close_tab is for individual tabs or that browser_stop_recording stops recording without closing.

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 reveals that closing a tab makes another active if it was active, and cannot close the last tab. It does not mention irreversible state changes or other side effects, which is acceptable for a simple close 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 sentences front-load the main action and immediately address the key constraint (last tab). No wasted words; every sentence adds value.

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

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

For a simple tool with 1 parameter and no output schema, the description covers the essential behavior, constraints, and fallback tool. It could mention that the tab must be open, but that is implied. Sufficient for basic use.

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 description adds minimal value beyond the schema's parameter description. It implies the tab id is the identifier, matching schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the action (close), the resource (tab by id), and explicitly distinguishes from the sibling tool 'browser_close' by noting that it cannot close the last tab, directing to browser_close for session end.

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

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

It provides clear guidance on when to use (close a tab by id) and when not to (cannot close last tab, use browser_close instead). The exclusion is explicit, though it does not discuss alternatives like browser_switch_tab.

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?

Without annotations, the description clearly states the action: disabling all active rules. It lacks details on side effects (e.g., in-flight requests) or permissions, but the simplicity of the tool mitigates the need for deeper disclosure.

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

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

A single sentence that directly states the tool's action with no extraneous words. Every word earns its place.

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

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

For a zero-parameter tool with no output schema and a straightforward action, the description is complete. It tells the agent exactly what will happen.

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

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

There are no parameters, so schema coverage is 100%. The description does not need to add parameter meaning, aligning with the baseline high score.

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 ('Disable') and resource ('all active network request interception rules'), clearly distinguishing it from the sibling tool browser_intercept_request which enables interception.

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

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

The description implies usage context as the inverse of enabling interception, but provides no explicit guidance on when to use or when not to use it, and does not mention 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 provided, the description carries the full burden. It discloses the in-memory nature, rolling buffer size (10 seconds), and output format. It does not mention potential side effects (e.g., file overwrite) or authentication needs, but the most critical behavioral traits are covered.

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

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

Two concise sentences with no wasted words. The purpose is front-loaded, and every sentence adds value. Ideal length for this simple tool.

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 has one optional parameter, no output schema, and no annotations, the description is fairly complete. It covers the core function, input, output, and use case. Could optionally note that existing files might be overwritten, but not essential.

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 parameter 'outputPath' is well-described in the schema itself. The tool description adds no additional meaning beyond what the schema already provides, 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 verb 'dump', the resource 'rolling in-memory DVR visual buffer' with specific recency ('last 10 seconds'), and the output format ('JPEG files'). This distinguishes it from related sibling tools like browser_replay or browser_start_recording.

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 frames the tool as useful for inspecting what occurred immediately before a failure, giving clear context for when to use it. However, it does not mention when not to use it or explicitly name alternatives among siblings.

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 provided, but description discloses key behaviors: captures final actions, returns summary (interactions, time span, completion signal), hands control back, and notes data is in durable archive. Adequately informs agent of side effects.

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

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

Two sentences: first states action and outcome, second provides context and follow-up options. No wasted words, 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 0-parameter tool with no output schema, the description explains return summary sufficiently and provides post-handoff guidance. Complete and actionable.

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?

No parameters, so schema covers 100%. Description adds no parameter info, which is acceptable. Baseline 3, but penalizing slightly would be too strict; the description does not mislead and is helpful.

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 clearly states the tool ends a human handoff, captures final actions, returns a summary, and hands control back. It distinguishes itself from sibling tools like browser_begin_handoff by explaining the handoff lifecycle.

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?

Describes when to use (after begin_handoff) and provides explicit alternatives for processing captured data (timetravel, diagnose, propose skill). Lacks an explicit 'when not to use' but 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool uses a recorded temporal timeline, linking to network requests, console errors, and DOM mutations. It does not mention side effects, rate limits, or auth needs, but given the read-only nature, the description 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?

The description is highly concise, consisting of two sentences plus a usage directive. It front-loads key terms ('CAUSAL EXPLAINABILITY') and avoids redundancy. Every sentence serves a purpose.

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

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

Given the tool's low complexity (one optional parameter, no output schema), the description adequately covers its behavior and use case. It explains what the tool links to (network requests, console errors, DOM mutations) but does not describe the output format, which could be helpful.

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

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

Schema coverage is 100% for the single parameter `windowMs`, with a description provided. The tool description does not add further meaning beyond what the schema already states. 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 specifies the tool's purpose: explaining why the page is in its current state by linking recent actions to network requests, console errors, and DOM mutations. It uses specific verbs and resources (e.g., 'explain', 'causal', 'temporal timeline') and distinguishes itself from snapshot-based tools, though it does not name specific siblings.

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

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

The description explicitly states when to use the tool: 'Call this right after an action that behaved unexpectedly.' This provides clear context for invocation. However, it does not explicitly mention when not to use it or suggest alternative tools for expected behaviors, leaving some gap in coverage.

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?

Discloses that bodies are redacted and size-capped, only textual responses captured, and env variable to disable body capture. No mention of permissions or post-export behavior, but adequate given no 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?

Four sentences, each adding value: main purpose, use case, limitation (redaction), configuration option. 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?

No output schema, but description mentions 'return it inline' and format (HAR). Slight gap in detailing returned structure, but sufficient for a simple export 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 baseline is 3. Description does not add extra meaning beyond schema descriptions; it focuses on output content rather than 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?

Description clearly states the tool exports network traffic as HAR 1.2 archive, lists contents (headers, bodies, statuses, timings), and distinguishes by highlighting this is how to get actual API error payloads.

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?

Implicitly suggests usage for inspecting error details beyond status codes, but does not explicitly compare to alternatives like browser_export_repro or state when not to use.

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 what is exported (actions, navigations, network failures), but does not mention whether the session is modified, whether it requires specific permissions, or the behavior when savePath is omitted. The export nature implies read-only, but this is not explicitly stated.

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 consists of two sentences with no wasted words. It is front-loaded with the verb 'Export' and clearly conveys the purpose and content. Every sentence earns its place.

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

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

The tool has low complexity (one optional param, no output schema). The description explains what is exported and the use case. However, it does not specify what happens when savePath is omitted (presumably returns data in response) or describe the output format explicitly.

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 for the single optional parameter savePath, which is described as 'Optional path... to also write the repro bundle JSON.' The description adds no additional meaning beyond the schema, so a 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 clearly states the tool exports a portable reproduction bundle containing actions, navigations, and network failures. It uses specific verbs ('export', 'turn into') and specifies the output. However, it does not explicitly distinguish itself from the sibling tool browser_export_har, which exports a different format (HAR).

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 use this tool after reproducing a bug, to generate a shareable repro script. This provides clear context for when to use it, but it does not mention when not to use it or alternatives like browser_export_har.

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 the tool searches across all frames and penetrates shadow DOMs using the Puppeteer engine. It does not mention any side effects, but the tool is inherently read-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?

The description is two sentences and a follow-up hint, all front-loaded with purpose and usage context. Every sentence adds value 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?

No output schema, but the description mentions return values (bounding boxes, text content) and hints at using coordinates with other tools. Parameters are fully covered. It provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minor details: case-insensitive fuzzy match for 'text', default values for 'timeoutMs' and 'visibleOnly'. These are useful but largely covered by the schema descriptions.

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

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

The description clearly states the tool finds elements matching fuzzy text and returns bounding boxes and text content. It distinguishes itself as a fallback when the AX tree is broken or elements lack semantic meaning, and mentions searching across frames and shadow DOMs.

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 frames the tool as a 'crucial fallback when the AX tree is broken or an element lacks semantic meaning,' providing strong guidance on when to use it. It does not explicitly list exclusions or alternatives, 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?

No annotations are provided, so the description carries the full burden. It states it is a read operation ('Get...') but does not disclose any behavioral traits such as whether the element must be visible, the performance impact, or default return format (e.g., returns all styles if no properties filter). This is minimal disclosure.

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

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

The description consists of two concise sentences with no filler. It is front-loaded with the core action and immediately follows with usage guidance. Every sentence adds value.

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

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

Given no output schema, the description should explain what the tool returns (e.g., an object of computed styles). It does not. Additionally, it does not address prerequisites (e.g., element must be in DOM) or edge cases. The complexity is moderate, but gaps remain.

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?

Input schema has 100% coverage, so baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions. It mentions filtering via 'properties' in the usage hint, but this is already 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 clearly states the action ('Get the computed CSS styles') and the resource ('a specific element'). It also distinguishes the tool from siblings by noting it is for visual changes 'not reflected in the accessibility tree', providing precise 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 guides usage: 'Use this to verify visual changes like colors, fonts, or dimensions that are not reflected in the accessibility tree.' This gives clear context and implicit when-not-to-use, but does not name alternative tools for cases where accessibility tree suffices.

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 mentions automatic iframe traversal, a useful behavioral trait. However, it does not disclose potential side effects (e.g., whether it changes state) or behavior on out-of-bounds coordinates. For a read-like tool, this is adequate but could be more 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 sentences with no wasted words. The first sentence immediately states the core purpose, followed by a concise list of returns and a key behavioral note.

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 output schema, the description adequately explains return values and special behavior (iframe traversal). Minor gaps include lack of error conditions (e.g., out-of-bounds) and handling of invisible elements, but overall sufficient for a simple retrieval 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% with clear descriptions for x and y coordinates. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.

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

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

The description clearly states the tool gets the topmost element at given coordinates and returns specific data (tag, text, backendNodeId). It distinguishes from sibling tools like coordinate_click or get_element_tree by focusing on retrieval rather than interaction or full tree.

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

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

The description implies usage for inspecting elements at a point, but lacks explicit guidance on when to prefer this over alternatives (e.g., coordinate_click for clicking, get_element_tree for broader context). No when-not-to-use or exclusions provided.

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

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

No annotations are provided, so the description carries full burden. It states the tool retrieves 'all active' listeners, but does not disclose whether this is a read-only operation, whether it requires the page to be fully loaded, or what happens if the element has no listeners. More behavioral details are needed.

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

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

The description is two sentences, front-loaded with the core action, and contains no extraneous information. 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?

Despite low complexity and full schema coverage, the description lacks completeness. There is no output schema, yet the description fails to mention what the tool returns (e.g., a list of listener objects with properties). The agent is left guessing the return structure.

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 documented in the schema. The description adds no additional meaning or context beyond what the schema provides, resulting in a baseline score of 3.

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

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

The description specifies 'Get all active JavaScript event listeners attached to an element' with a clear verb and resource. It adds context about usefulness for understanding interactive behavior before dispatching events, but does not explicitly distinguish it from similar DOM inspection sibling tools like browser_get_computed_style or browser_get_outer_html.

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

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

The description hints at usage when 'understanding interactive behavior before dispatching events', providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives, and does not state any prerequisites 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?

No annotations provided, but description discloses raw HTML output, token expense, and truncation to maxLength. Could mention absence of side effects but sufficient given 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 focused sentences: purpose, usage guidance, and output limitation. No redundant text, though slightly verbose with 'DEBUG FALLBACK' label.

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 output schema and no annotations, description covers purpose, usage context, and truncation. Lacks explanation of return format but name implies raw 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?

Schema coverage is 100%. Description adds value by explaining default maxLength, optional backendNodeId meaning, and truncation behavior beyond 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 retrieves raw outerHTML of a DOM element by backendNodeId, with a fallback to document root. It distinguishes itself from sibling get_semantic_surface as a debug fallback.

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 advises when to use (when get_semantic_surface returns empty tree) and when not (prefer get_semantic_surface). Includes warning about token cost and positions it exclusively for debugging.

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 implies a read operation but doesn't state side effects, prerequisites (e.g., page loaded), or availability of metrics. The examples suggest the return format but not behavioral nuances.

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

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

Single sentence, front-loaded, no wasted words. Every part adds value.

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

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

For a zero-parameter tool with no output schema, the description is complete: it explains what the tool returns with examples, sufficient for an agent to understand its use.

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?

No parameters exist, and schema coverage is 100% (empty). The description adds no param info, but the baseline for zero-parameter tools is high; additional context about returned metrics is provided.

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

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

The description clearly states the verb 'Get', the resource 'Chromium internal performance and rendering metrics', and provides specific examples (Nodes, JSHeapUsedSize, LayoutCount), distinguishing it from sibling tools like browser_get_computed_style or browser_get_timeline.

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 on when to use this tool vs alternatives; no when-not or context provided. Given many similar browser get tools, explicit usage advice is missing.

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 fully explains the behavioral traits: provenance tags, trust levels, and the warning about page-controlled events. It adds value by cautioning against treating page-authored text as instructions. However, it does not explicitly state that the operation is read-only, which is implicit.

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

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

Three concise sentences: purpose, detailed trust explanation, usage advice. No fluff, well-structured, and front-loaded with key 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?

The description covers the tool's purpose, trust tags, and usage advice. It is complete for a tool with 2 parameters and no output schema, though it could mention that it's a non-destructive read 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?

Schema coverage is 100%, so the description's main addition is explaining the trust enum values and their significance. It also mentions the default limit of 50. This adds context beyond the schema's basic descriptions.

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

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

The description clearly states the tool returns a 'recent unified event timeline' with specific event types and provenance tags. It uses a specific verb ('Return') and resource, and distinguishes from siblings like browser_query_timeline by mentioning provenance tags.

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 guidance on using the trust tag to avoid acting on injected instructions, but does not explicitly state when to use this tool versus alternatives like browser_query_timeline. The usage context is clear but lacks explicit comparisons 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 bears full burden. It discloses the three main actions (delay, fail, mock) and references CDP Fetch, but lacks details on side effects, persistence, conflicts, or cleanup, leaving behavioral transparency partially incomplete.

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 fluff. The first sentence front-loads the core action and available behaviors, making it highly efficient for an agent to quickly grasp the tool's purpose.

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

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

The description covers the tool's core operations and mentions CDP Fetch, but omits return value behavior (no output schema) and does not reference related lifecycle tools like browser_disable_interception. For a tool with nested parameters and no output schema, it is adequate but could be more complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond what the schema already provides (e.g., CDP Fetch context). It does not enhance parameter understanding significantly.

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 intercepts network requests to inject delays, force failures, or return mock responses, using CDP Fetch domain. It provides a specific verb-resource combination and scope, though it does not explicitly differentiate from sibling tools like browser_throttle_network.

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

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

The description implies usage for testing and mocking network requests, but does not provide explicit guidance on when to use versus alternatives (e.g., browser_throttle_network) or conditions where interception is not appropriate.

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

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

With no annotations, the description provides thorough behavioral details: headless default, immediate navigation with load event wait, automatic enabling of Accessibility, DOM, Performance domains, and Target.setAutoAttach. It also discloses the implicit recording conflict with autoTrackHistory. No annotations to contradict.

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

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

The description is concise (4-5 sentences) with no redundant information. It front-loads core purpose and mandatory nature, then lists key behaviors and parameters efficiently. Every sentence contributes meaningful information.

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

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

Given the tool's complexity (launch, CDP session, navigation, history recording), the description covers all essential aspects. It explains what happens after launch, default modes, parameter effects, and preset automations. No output schema is needed as return values are implied (session created). It is fully complete from an agent's perspective.

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 baseline is 3. The description adds value by stating defaults (headless true), explaining the implicit recording behavior for autoTrackHistory, and noting the default sessionHistoryDir path. This extra context justifies a 4.

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

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

The description clearly states the tool's action: 'Launch a Chromium browser instance and establish a CDP session.' It explicitly marks this as the mandatory first step, distinguishing it from other browser tools. The verb 'launch' is specific to the resource 'browser instance', and the mandatory nature sets clear 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 says 'This is the mandatory first step before any other tool can be used.' It provides guidance on headless mode vs visual debugging, URL navigation, and autoTrackHistory with a conflict warning. This fully addresses when and how to use the tool.

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

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

No annotations provided; description discloses ordering (newest first) and output fields, but does not discuss side effects, permissions, or limitations. Adequate for a read-only list.

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, front-loaded with 'TIME MACHINE' label, no redundancy, every word serves a purpose.

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

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

For a zero-parameter, no-output-schema tool, the description fully covers what the tool does and how to use the result. No gaps.

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

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

No parameters; schema coverage 100% trivially. Description adds no param details, but for 0 parameters this is acceptable and the description adds value by showing what the output contains.

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?

Clearly states it lists durably saved session archives sorted newest first, specifying the output fields (id, origin, time span, counts) and linking to the load tool. Distinguishes itself from siblings like browser_save_session, browser_load_session.

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

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

Explicitly says to load a session with browser_load_session, implying the use case. Missing explicit when-not-to-use or alternatives, but the context is clear for a listing 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 behavioral burden and effectively explains the meaning of each status value, implying a read-only, safe operation without destructive side effects.

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

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

The description is extremely concise with only two sentences, each adding distinct value: the first defines the tool's output, and the second provides usage guidance. No superfluous 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?

Without an output schema, the description does not specify the exact return format, but it adequately covers the key concepts (skills and their statuses) and gives a practical reason to use 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?

Although the schema already lists the enum values, the description adds semantic depth by clarifying what each status represents (e.g., 'proposed, not yet gated'), enhancing understanding beyond the raw 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 explicitly states the tool lists skills learned for the current origin and enumerates the possible statuses with clear definitions, leaving no ambiguity about its function.

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 usage example ('Use this to see which flows you can trust to replay'), indicating when to apply the tool, though it does not explicitly contrast with sibling tools 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, description carries full burden. It correctly implies read-only behavior and what it returns, but does not explicitly state side effects 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?

Single sentence, highly concise, front-loaded with key information. 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?

Given zero parameters and simple functionality, the description is mostly complete. It explains the return values, which is important since there is no output schema. Minor: could mention scope ('current browser session').

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

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

There are no parameters, so baseline is 4. Description adds value by specifying the output fields (ids, URLs, active status) beyond the empty schema.

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

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

The description clearly states it lists open tabs with ids, URLs, and active status. It distinguishes the tool's output from sibling tools like browser_switch_tab that use tab ids, but does not explicitly differentiate between 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 on when to use this tool instead of alternatives, or prerequisites. Users must infer its use from 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?

With no annotations provided, the description carries the full burden. It clearly states the tool loads a session archive, returns metadata, and is used for investigation. It does not disclose potential side effects, but given the read-only nature (implied by 'load'), this is acceptable.

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 wasted words. The key action ('Load a saved session archive') is front-loaded, and the metaphor is efficient. Every sentence adds value.

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

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

Given the tool has only one parameter and no output schema, the description adequately covers its purpose and usage. It could be improved by briefly indicating what the 'session metadata' contains, but it is still fairly complete for a simple load 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?

Schema description coverage is 100% for the single parameter 'id', whose description ('The session id from browser_list_sessions') is already provided. The tool description adds no additional meaning beyond the schema, so 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?

The description uses a vivid metaphor ('TIME MACHINE') and clearly states the verb 'load' and resource 'saved session archive'. It distinguishes the tool from siblings like browser_save_session by specifying it loads archives for investigation via browser_timetravel.

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 ('investigate a past session (yours or one recorded earlier)') and implicitly frames it as a preparatory step for browser_timetravel. However, it does not mention when not to use it or compare directly with alternatives like browser_replay.

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 disclose behavioral traits. It covers basic functionality but omits details like domain scope for cookies, that clearing localStorage affects the current origin, and that 'set' requires both key and value (implied but not explicit). The description lacks some context for safe 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 sentences with no wasted words. The first sentence defines functionality, the second provides usage context. Information is front-loaded and easy to parse.

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

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

The tool has 5 parameters and no output schema. The description covers the core actions but lacks details on return values, domain behavior, and precondition requirements. Given sibling tools and the complexity, it is adequate but not 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%, so baseline is 3. The description restates the storage types and actions but adds no new parameter details beyond the schema. It does not explain conditional requirements (e.g., domain for cookies) or output format.

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

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

The description clearly states the action verbs (get, set, clear) and resource (browser storage: localStorage, sessionStorage, cookies). It distinguishes from sibling tools by specifying storage manipulation, which is unique among the browser tools listed.

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

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

The description provides explicit use cases: 'testing auth flows, clearing state between test runs, or inspecting cached data.' This guides the agent on when to use the tool, though it does not contrast with 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?

No annotations are provided, so the description carries full burden. It discloses that the tool overrides Date, Date.now(), and performance.now() and that changes persist across page navigations. This is good but could further detail boundaries (e.g., effect on other tabs, limitations).

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

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

The description is two sentences, front-loaded with the core action and key details. Every sentence adds necessary information with no superfluous 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 tool with no annotations and no output schema, the description covers the essential behavior: what it does, what it overrides, and persistence. It could mention return values or confirmation, but overall sufficiently complete for its 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?

Schema coverage is 100% and the description adds no additional meaning beyond what the schema provides for each parameter. Baseline 3 is appropriate as the schema already documents mode, deltaMs, and isoDate with clear 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?

Description uses specific verbs ('mock, freeze, or shift') and clearly identifies the resource ('browser time') and its scope (overrides Date, Date.now(), performance.now(), persists across navigations). It distinguishes itself from sibling tools, none of which perform time mocking.

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 use for deterministic testing but provides no explicit guidance on when to use this tool versus alternatives, nor when it should not be used. Given no competing time-mocking siblings, the context is clear but formally lacking.

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 full burden. It discloses the default wait strategy and options for different page types, but does not mention return values, error handling, timeouts, or behavior on invalid URLs.

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 primary purpose, specific usage advice, and follow-up action. Every sentence is essential and efficiently written.

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 four parameters and no output schema, the description covers navigation behavior and wait options but omits return values, error scenarios, and timeout handling. While helpful, it leaves gaps for an agent to fully understand the tool's behavior.

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 description adds value by explaining wait strategies in context (e.g., SPAs), defaults, and the use of returnDelta. It provides meaningful guidance beyond parameter names and schema descriptions.

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

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

The description clearly states the action ('Navigate the active browser tab to a new URL') with a specific verb and resource. It distinguishes from sibling tools like browser_new_tab and provides context about waiting 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?

Provides explicit guidance on when to use waitUntil='networkidle0' for SPAs and suggests calling get_semantic_surface after navigation. However, it does not explicitly state when not to use this tool or compare to alternatives like browser_switch_tab.

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 provided; description explains that the tool opens and switches to a new tab and that subsequent tools operate on it. Lacks details on whether it creates a new window or tab, but is adequate for a simple 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?

Two sentences: first states action and effect, second provides use cases. Front-loaded and no extraneous text.

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 simple tool (1 param, no output schema), description covers main purpose and use cases. Minor gap: no mention of return value or behavior when no URL is provided.

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% with one optional 'url' parameter. Description repeats 'Optional URL' without adding new semantics like default behavior.

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

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

Description clearly states the tool opens a new browser tab and switches focus to it, with specific use cases (OAuth popups, payment redirects, cross-tab verification). This distinguishes it from siblings like browser_switch_tab.

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 lists scenarios for use (OAuth, payment redirects, cross-tab verification), implying context. Does not explicitly state when not to use, but the sibling list provides 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?

Since no annotations are provided, description carries full burden. It explains that the candidate is quarantined, not trusted until validation. Discloses the two components: action bundle and probe. Does not explicitly mention storage or side effects, but is fairly 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?

Description is concise, front-loaded with 'ACTIVE MEMORY (step 1 of 2)', and each sentence adds value 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?

Given no output schema, description explains the outcome (quarantine) and the two-step learning process. Lacks details on state persistence or limits, but is fairly complete for a tool in a multi-step flow.

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 baseline is 3. Description adds context about assertions as end-state probes but does not significantly enhance parameter understanding 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?

Description clearly states it is step 1 of 2 for creating a skill, proposing the current session as a candidate. It distinguishes from sibling 'browser_validate_skill' which validates the candidate.

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 says when to use (to learn a flow) and when not to trust the candidate until validation. Mentions the alternative 'browser_validate_skill' for the next step.

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 automatic iframe piercing, return fields (backendNodeIds, text, bounding boxes), and implies non-destructive read. Minor missing details (e.g., behavior on missing element) but overall adequate.

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 focused sentences with no redundancy. Core function, frame piercing, usage guidance, and integration hint for atomic_interact are each addressed concisely.

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 no output schema, the description sufficiently explains return values and behavior (iframe piercing). For a query tool with well-defined parameters, it covers all needed 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 coverage is 100%, so baseline 3. Description adds marginal value by reinforcing XPath prefix usage but does not add significant new meaning beyond the schema.

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

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

The description clearly states the tool queries the DOM using CSS or XPath and returns matching elements with backendNodeIds, text, and bounding boxes. It also mentions automatic iframe piercing, distinguishing it from siblings like get_semantic_surface.

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 advises preferring get_semantic_surface for page understanding and specifies this tool for CSS selectors not surfaced by the AX tree. Also notes returned backendNodeIds can be used with atomic_interact, providing clear when-to-use and 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 provided, the description carries the full burden of behavioral disclosure. It mentions the tool queries a timeline and operates on a session, but does not state that it is read-only, discuss auth requirements, performance impact, or what happens to the session. The description is sufficient for basic understanding but lacks detail on 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?

The description is extremely concise, with a clear header 'TRACE-AS-DATABASE', a one-sentence purpose, illustrative examples, and a closing remark about session state. Every sentence is purposeful and there is 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?

Given the tool has 9 parameters and no output schema, the description provides a good high-level overview and examples but does not explain the return format, pagination, or error cases. It is adequate for a query tool but lacks some completeness for an agent to fully understand the output behavior.

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% coverage with descriptions for each parameter, so the baseline is 3. The description adds value by providing usage examples (e.g., '{ kind: "network", statusGte: 500 }') and explaining how parameters like 'textContains' work, which enhances understanding beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: querying the recorded session timeline for events matching a predicate, with specific examples like network errors and console errors. It distinguishes from siblings by focusing on querying rather than exporting or managing sessions, but does not explicitly differentiate from 'browser_get_timeline' which likely retrieves the full timeline.

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 context on when the tool operates (loaded past session or live session) but gives no guidance on when to use this tool over alternatives such as 'browser_get_timeline' or 'browser_dump_dvr'. There is no discussion of prerequisites, limitations, or 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 provided, so description carries the burden. It explains the return value (memories or null) and implies read-only behavior. However, it does not explicitly state side effects or safety, but given the recall nature, it is sufficiently 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?

Description is front-loaded with 'SITE MEMORY' and provides a clear list of recall types. Every sentence adds value, though could be slightly more concise without losing meaning.

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 completeness: purpose, usage, return value. Minor gap on exact format of returned data, but contextually adequate.

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

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

Zero parameters and 100% schema coverage, so description adds no param info but none is needed. Baseline score of 4 is appropriate.

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

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

The description clearly states it recalls learned information about the current origin, listing specific types: landmarks, action flows, gotchas, trusted skills. This purpose is unique among sibling tools, which focus on replay, saving, etc.

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 says 'Call this right after navigating to a site you may have visited before' and notes that it returns null for new origins, providing 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?

No annotations provided, so the description carries the full burden. It discloses deterministic replay, coordinate-based actions, and the step-by-step report output. It does not cover potential side effects or authentication needs, but for a replay tool the description is sufficiently 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 sentences with no wasted words. The key information is front-loaded: the purpose, the deterministic nature, and the parameter usage.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers what the tool does, how to use it, and what it returns. It is complete for an agent to decide when and how to 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 coverage is 100% and the schema describes bundlePath. The description adds value by explaining that omitting bundlePath replays the current session and that the bundle comes from browser_export_repro, which aids selection.

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 replays a recorded session to reproduce a bug. The verb 'replay' and resource 'recorded session' are specific, and it distinguishes from siblings like browser_export_repro (export) and browser_start_recording (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?

It explains when to use bundlePath (for previously exported bundles) vs omitting it (current session). It does not explicitly state when not to use the tool or list alternatives, but the context is clear given sibling tools like browser_run_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 full burden for behavioral disclosure. It reveals that the tool returns replay coverage (steps replayed vs. skipped) and assertion results, but does not clarify side effects, mutability, or prerequisites (e.g., whether the scenario must 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?

The description is two sentences: the first conveys the core purpose, the second details the return value. No wasted words, front-loaded, and easy to parse.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description adequately covers purpose, inputs, and outputs. It lacks mention of error states or prerequisites, but remains largely complete for a replay 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% with the `name` parameter described as 'The scenario name to run.' The description adds no additional meaning or constraints beyond the schema, so 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 clearly states the tool replays a saved scenario and checks assertions, framing it as a pass/fail regression run. This distinguishes it from siblings like `browser_replay` (which likely only replays) by emphasizing assertion checking and regression testing.

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

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

The description implies usage for regression testing of saved scenarios, but does not explicitly state when to use this tool over alternatives like `browser_replay` or `browser_save_scenario`. No prerequisites or exclusions are mentioned.

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

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

No annotations are provided, so description bears full burden. It discloses that the tool records actions and assertions, and implies a non-destructive save. However, it doesn't detail permission requirements or side effects, but the behavior is well described.

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 redundancy, front-loaded with 'EVAL / REGRESSION'. Every sentence contributes essential information.

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

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

Given no output schema and only 2 parameters, the description covers purpose, usage, and parameter semantics well. Could mention whether the tool requires a session to be active, but overall complete.

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

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

Schema coverage is 100%, but the description adds value by explaining 'end-state assertions' with concrete examples (e.g., 'text Order confirmed is visible'), enhancing understanding 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 saves the current session as a named, replayable scenario including action bundle and end-state assertions. It distinguishes from sibling tools like browser_run_scenario by mentioning replay and regression testing.

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 'EVAL / REGRESSION' and that later browser_run_scenario replays it, providing clear context. It doesn't explicitly mention when not to use or alternative tools for saving vs. exporting, but the purpose is clear enough.

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

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

The description details what is saved (provenance-tagged timeline, keyframes) and that it is durable. No annotations exist, so the description carries full burden. It lacks information on potential side effects or performance impact.

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, efficiently packed with key information. The 'TIME MACHINE' opener is attention-grabbing but slightly extraneous. Overall, concise and well-organized.

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 simple parameter set (one optional param) and no output schema, the description adequately covers purpose, usage, and saved content. It could mention return value or error conditions but is mostly complete.

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

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

The only parameter 'name' has a description in the schema and is repeated in the tool description. With 100% schema coverage, the description adds no extra semantic value 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 clearly states the tool saves the current session as a replayable archive, distinguishing it from siblings like browser_load_session and browser_replay. The phrase 'TIME MACHINE' emphasizes its role as a durable snapshot.

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

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

The description explains when to use this tool ('snapshot mid-session or name it') and contrasts with auto-save on browser_close. However, it does not explicitly mention when not to use it relative to sibling tools like browser_save_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. It discloses that returns a compressed JPEG by default and explains options like fullPage and highlightNodeIds. However, it lacks details on blocking behavior, side effects (e.g., scrolling), or permissions, leaving some behavioral traits 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 concise with a clear structure: a summary sentence followed by a bullet list of options. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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

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

The description explains the core functionality and options but omits details about the return format (e.g., base64 vs. file) and blocking nature. Given no output schema, the return value description is incomplete, and the level of detail is adequate but not comprehensive.

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 some context for options like fullPage and highlightNodeIds beyond the schema, but the gains are marginal. The default format and quality are noted but not deeply elaborated.

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 'Capture a screenshot of the current page' with a specific verb and resource. It also distinguishes from stream_screencast for non-blocking capture, making the purpose distinct from siblings.

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

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

The description explicitly recommends stream_screencast for non-blocking visual capture, providing a clear alternative. However, it does not cover all siblings or provide comprehensive when-to-use guidance beyond that one distinction.

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 provided, so the description carries full burden. It discloses the core behavior (toggle network) but does not mention side effects like impact on all tabs or ongoing requests. Adequate but not rich.

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: first states the purpose, second lists use cases. No wasted words, front-loaded with key info. Very concise and well-structured.

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

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

Given the tool has one required parameter and no output schema, the description is complete. It explains what the tool does and when to use it. No missing information needed for correct selection and invocation.

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 'offline' has a clear description in the schema: 'true = go offline, false = restore connectivity'. Since schema coverage is 100%, the description adds no extra value beyond the schema. 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 toggles browser network between online and offline. It has a specific verb ('toggle'), resource ('browser network'), and distinguishes it from siblings like browser_throttle_network.

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 lists three use cases: testing PWA offline behavior, Service Worker fallbacks, and error handling for network failures. It does not mention when not to use or alternatives, 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, the description fully conveys behavior: simulates Tab presses, reports focus order with element details and backendNodeIds, flags potential traps. It implies a read-only audit without side effects.

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

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

Two focused sentences front-load the action and purpose, with output details following. No extraneous 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?

Despite lacking an output schema, the description clearly states what is reported (focus order, element details, backendNodeIds, trap flags). Sufficient for a simple tool with one optional parameter.

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

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

Schema coverage is 100% for the single parameter maxSteps, and the description does not add extra meaning beyond the schema's own description. Baseline score applied.

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 clearly states the tool simulates Tab pressing to audit keyboard accessibility, distinguishing it from other browser interaction tools like atomic_interact or coordinate_click.

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 provides a clear context for use: 'audit keyboard accessibility'. It does not explicitly mention when not to use or alternatives, but the 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?

Discloses key behaviors: starts background recording, auto-stops after 5 minutes of inactivity, and interaction with browser_launch's autoTrackHistory. No annotations provided, so description carries the burden; additional details would improve 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?

Extremely concise: two sentences plus a note about autoTrackHistory. Front-loads the main purpose without unnecessary detail.

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 essential aspects of recording start, auto-stop, and implicit recording interaction. Lacks details on output format, performance impact, or how to retrieve the compiled video, but these may be covered by sibling 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?

Only one optional parameter (outputDir) with schema description already covering its purpose and default. The tool description adds no extra parameter context beyond what the schema provides, meeting baseline expectations.

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 clearly states the tool starts recording screencast frames to compile a video, with specific details on auto-stop and finalization via browser_stop_recording, distinguishing it from sibling 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?

Describes when to use (start recording) and notes the interaction with autoTrackHistory, providing clear context for usage, though it does not explicitly exclude alternatives like stream_screencast.

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 must fully disclose behavior. It states the tool shows changes without modifying state, but does not explicitly say it is read-only, or mention permissions or side effects. This is adequate but leaves some ambiguity.

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 very concise: a bold summary, a list of what changes are shown, and a practical use case. Every sentence adds value with no wasted words.

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

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

The tool has no output schema, so the description must explain the return. It enumerates the categories of changes (storage, URL, navigations, etc.), which is sufficient for an agent to understand the output. Minor missing detail like the format of timestamps, but overall complete.

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

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

The schema already describes each parameter with types and allowed values (anchor, timestamp, 'last_error'), achieving 100% coverage. The description adds context by mentioning 'from browser_timetravel' and giving examples, which adds value 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's purpose: diff two moments and show what changed (localStorage, URL, actions, errors, etc.). It uses a specific verb ('DIFF') and resource ('TWO MOMENTS') and provides a concrete use case, distinguishing it from sibling tools like browser_timetravel or get_state_delta.

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 on when to use it ('the fast way to answer what actually changed') and specifies valid inputs (anchor tokens, timestamps, 'last_error'). However, it does not explicitly exclude scenarios or mention alternatives, which would elevate it to 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?

No annotations are provided, so the description carries the full burden. It discloses that the recording is stopped and frames are compiled to MP4 using FFmpeg, which implies a dependency and a destructive action. However, it does not describe what happens to the output file (e.g., where it is saved, if it's returned) or error behavior (e.g., if no active recording exists).

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

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

The description is a single, well-constructed sentence that delivers the key action and outcome. It is front-loaded and contains no extraneous words, earning its place with high efficiency.

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 output schema, no annotations, and no parameters, the description is the sole source of context. It covers the core behavior but lacks details on output (return value, file location), prerequisites (active recording, FFmpeg installation), and edge cases (no active recording). This leaves gaps for a tool with no other structured information.

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 covers 100% of them (none). The description does not need to add parameter-level meaning, and the baseline for zero parameters is 4. No additional parameter information is necessary.

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 ('Stop'), identifies the resource ('the active recording'), and states the outcome ('compile the frames into an MP4 video using FFmpeg'). This clearly distinguishes it from sibling tools like browser_start_recording (starts) or browser_dump_dvr (dumps raw data).

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

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

The description implies usage when there is an active recording that needs to be finalized, but lacks explicit guidance on when to use this tool versus alternatives (e.g., browser_dump_dvr), prerequisites, or conditions under which it should not be used.

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

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

With no annotations, the description carries full burden. It discloses that switching affects subsequent tool operations. No mention of destructive actions or prerequisites beyond list_tabs, but for a simple state change, this is sufficient.

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

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

Two sentences, directly to the point. First sentence states the primary action; second provides essential context. No superfluous 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?

Given the simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: purpose, effect, and parameter source. It is complete enough for an agent to use 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 schema already describes the parameter. The description adds value by telling the agent to get tab ids from browser_list_tabs, but beyond that, it adds little to the schema's own description.

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

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

The description clearly states the verb 'Switch' and resource 'active tab', distinguishing it from siblings like browser_new_tab and browser_close_tab. It also explains that subsequent tools operate on this tab, adding specificity.

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 tells when to use the tool (before perception/interaction tools) and where to get the tab id (from browser_list_tabs). It does not explicitly state when not to use or list alternatives, but the context is clear given the sibling tools.

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

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

No annotations are provided, so the description must bear the full burden of behavioral disclosure. It discloses that the tool throttles bandwidth and adds latency, and that preset 'off' restores normal speed. However, it does not mention scope (e.g., whether throttling applies to all tabs or just the current one), persistence, or other side effects like potential impact on other browser operations.

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

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

The description is concise, with two short paragraphs. The first paragraph states the purpose and use cases; the second provides usage details. Every sentence adds value, and the structure is logical.

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

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

The description covers the tool's purpose, use cases, parameter behavior, and how to disable. Given that there is no output schema and the tool is simple (4 parameters), it is largely complete. A minor gap is the lack of clarity on scope (e.g., whether it affects the current browsing context only).

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 all parameters are well-described in the schema. The description adds value by explaining the purpose of presets, giving example values, and clarifying that preset overrides raw parameters. It also explicitly states how to disable throttling.

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 ('emulate slow network conditions by throttling bandwidth and adding latency') and clearly identifies the resource (network conditions). It distinguishes this tool from sibling browser tools like navigate, screenshot, etc., which have different purposes.

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 ('testing loading states, skeleton screens, and timeout handling') and explains how to use it via presets or raw values, including how to disable throttling. It does not explicitly state when not to use it, but the guidance is clear and practical.

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

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

With no annotations, the description carries full burden. It discloses what is reconstructed (screen, storage, cookies, etc.) and that it works on past or live sessions. However, it omits side effects, permissions, failure modes, or performance implications. It does not contradict any structured fields.

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 front-loaded with the purpose and key capabilities. It uses some flamboyant language but remains efficient. A minor improvement could be trimming redundant emphasis.

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

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

Given the tool's complexity (time travel reconstruction, 5 params, no output schema, many siblings), the description covers what it does, how to use it, and the scope. It does not specify return values, but this is acceptable without an output schema. Overall, it provides sufficient context 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?

Schema coverage is 100%. The description adds value by explaining the meaning of parameters like beforeLastError, at, seq, and windowMs with context (e.g., 'most useful' for beforeLastError). This goes beyond the schema descriptions.

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

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

The description explicitly states the tool reconstructs everything at a single moment, distinguishing it from snapshot tools. It lists the reconstructed elements and contrasts with siblings like browser_recall_site or browser_get_timeline, making the purpose very 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 explains anchoring options (at, seq, beforeLastError) and recommends beforeLastError as most useful. It mentions operating on past or live sessions. However, it does not explicitly state when not to use this tool or list alternative tools for specific cases, leaving some room for improvement.

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 provided, so description carries full burden. It discloses validation logic (admit only if probe fully passes), side effects (demoting stale skills to STALE and recording gotchas), and emphasizes 'validated learning' that a replay cache cannot do. Lacks details on authorization or rate limits but adequately covers core 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?

Description is slightly verbose but every sentence adds value, explaining the step context, admission criteria, and side effects. Front-loaded with 'ACTIVE MEMORY (step 2 of 2)' and uses capitals for emphasis. Could be more concise, but not overly long.

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

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

Given the tool's complexity (validation gate with peer regression), description covers essential behavior: what it does, admission criteria, side effects, and return values (admit/reject decision, probe results, peer regressions). No output schema, but mentions return types. Lacks definition of 'probe' but overall complete for a step-by-step 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?

Only one parameter 'name' with schema description 'The candidate skill name to validate.' Since schema coverage is 100% and description adds no extra meaning beyond the schema, 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?

Description clearly states the tool's purpose: replay a candidate skill against the live site, check probe, admit only if passes, and re-check existing skills for drift. The verb 'validate' is specific, the resource 'skill' is clear, and it distinguishes from siblings like browser_replay and browser_propose_skill.

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 explicitly positions this as 'step 2 of 2 — THE GATE', implying it is the final validation step. It explains the admission decision and peer regression check. However, it does not explicitly state when not to use it or name alternatives beyond the context of replay cache.

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?

Discloses recording on timeline and return value format. No annotations, so description carries full burden. Does not mention whether it waits (timeoutMs implies waiting, but says 'right now'), nor prerequisites like browser state. Decent but not fully explicit.

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?

Concise three-sentence description, front-loaded with 'ASSERT / CHECKPOINT'. No wasted words, includes key details and usage example. Highly efficient.

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

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

Covers purpose, usage, and return. No output schema, but describes return shape. Could mention optionality of 'label' param, but overall complete for a tool with 4 params and moderate complexity.

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

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

Schema coverage is 75% (3 of 4 params described). Description adds value by referencing same vocab as browser_wait_for and giving example, but does not significantly supplement schema beyond that. 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?

Clearly states the tool is for verification/assertion ('Verify a condition holds right now') and recording results on the session timeline. Distinguishes from sibling browser_wait_for by emphasizing checkpointing vs waiting, and mentions same declarative vocabulary.

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 says to use for planting checkpoints while driving a flow, and compares to browser_wait_for. Does not explicitly state when not to use, but provides clear context for usage.

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?

Describes blocking nature and timeout behavior, but does not specify what happens on timeout (error vs return) or whether the tool is idempotent. Still, for a wait primitive, core behavior is 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?

Well-organized with heading, bullet use cases, and a tip. Every sentence serves a purpose. No fluff.

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

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

Covers all aspects: purpose, when to use, parameter behaviors, alternatives, and typical patterns. No output schema needed for a wait 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%, baseline 3. Description adds examples mapping types to use cases, default values for timeoutMs and durationMs, which goes beyond schema detail. Not full syntax but helpful.

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?

Clearly states it blocks until condition or timeout, replacing sleep-then-poll. Distinguishes from sibling atomic_interact by noting the combined action+wait pattern. Use cases list specific condition types.

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 contrasts with atomic_interact for 'act then wait', and gives clear use cases for each condition type. No ambiguity on when to use standalone vs combined.

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 full burden. It mentions the data source (recorded timeline + storage keyframes) and notes storage granularity. However, it doesn't disclose edge cases like behavior when no change is found, rate limits, or whether the operation is read-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?

The description is three sentences, front-loaded with the core concept, and each sentence adds essential detail: target types, anchor options, and data source. No redundant text.

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 5 parameters, no output schema, and no annotations, the description covers purpose and typical usage but lacks details on return format, error handling, and behavior when no change is found. It is adequate but not comprehensive.

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 schema already documents all parameters. The description adds concrete examples (e.g., type=storage with key='token') and clarifies the 'before' parameter options, but does not add significant new 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 starts with 'BACKWARD DATA-BREAKPOINT' and clearly states the tool finds when something last changed before a moment. It distinguishes from siblings like browser_timetravel or browser_query_timeline by focusing on last-change queries.

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

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

The description explains when to use (to find last change before a moment) and gives examples of targets and the 'before' anchor. However, it does not explicitly exclude alternatives or guide selection among siblings like browser_query_timeline.

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 provided, but description discloses that no spatial validation is performed and that it uses CDP Input.dispatchMouseEvent. Does not detail event propagation or side effects, but sufficient for a simple click 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 sentences, front-loaded with the bypass warning, no redundant text, every sentence adds value.

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

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

Given simple parameters, no output schema, but description provides full context for non-DOM usage and comparison to sibling, making it complete for an agent to decide and invoke.

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?

Input schema has 100% coverage with clear descriptions for x and y. Description adds no extra semantics beyond 'X pixel coordinate' and 'Y pixel coordinate', 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?

Clearly states it dispatches a raw mouse click at pixel coordinates via CDP Input.dispatchMouseEvent, explicitly for Canvas, WebGL, and non-DOM interfaces, distinguishing it from sibling atomic_interact.

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 warns to bypass DOM and specifies to prefer atomic_interact for DOM-based interactions, providing clear when-to-use and when-not-to.

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 provided, so description bears full burden. It discloses execution in frames and use of Target.setAutoAttach, but does not mention potential destructive side effects or security implications of executing arbitrary JS. Lacks a caution about mutating page state.

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?

Well-structured with sections (description, use cases, important note). Examples are helpful. Could be slightly more concise, but information density is good.

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, but description mentions 'result is returned as JSON'. Does not explain error handling (e.g., syntax errors, timeouts). With 3 params and full schema coverage, description covers usage but lacks edge-case behavior details.

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% with descriptions. Description adds value by explaining that omitting expression lists available frames and that frameIndex with no args also lists frames. This clarifies usage beyond 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?

Description clearly states 'Execute arbitrary JavaScript in any frame context' and provides specific use cases (inspecting state, reading styles, triggering app logic, executing in iframes). Distinguishes itself from sibling tools by being the general-purpose JS evaluation 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 lists use cases and when to use (e.g., inspecting React state, reading computed styles). Implicitly contrasts with framework-specific macros. Could improve by stating when not to use (e.g., for simple queries other tools might suffice).

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 full burden. It states it extracts the accessibility tree and returns interactive/text nodes, implying a read operation. However, it does not explicitly disclose behavioral traits like read-only nature, destructive potential, or performance impact. Some details are present but more would be expected.

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 consists of two sentences: the first clearly states purpose and output format, the second provides usage guidance. No unnecessary words or redundancy. It is front-loaded and efficient.

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

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

Given no output schema, the description could explain the Markdown output format in more detail. However, it covers the core functionality, when to use, and mentions the output is a hierarchical list with interactive/text nodes. Parameter behaviors are in the schema. Fairly complete for a tool with moderate complexity.

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

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

The input schema has 100% description coverage across all three parameters. The description does not add any additional meaning beyond what the schema already provides. According to guidelines, baseline is 3 when coverage is high, and no extra value is given.

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

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

The description clearly states it extracts the accessibility tree for a specific element and its descendants, returning a Markdown list. However, it does not differentiate from the sibling tool 'get_semantic_surface', which likely covers the full page. So purpose is clear but sibling distinction is missing.

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 advises using this tool when context about a specific panel, modal, or component is needed without fetching the entire page. This gives good context but does not mention when not to use it or provide alternatives like 'get_semantic_surface' for full-page extraction.

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 fully discloses behavioral traits: it queries the AX tree, resolves shadow roots, computes accessible names, pierces iframes, and runs serialization on a worker thread to avoid blocking. The options, like semanticOnly, are explained in terms of their pruning effect, ensuring the agent understands the tool's behavior and performance implications.

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

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

The description is well-structured with clear sections (capitalized headings) and front-loaded with the key purpose. However, it is somewhat verbose, containing multiple paragraphs. While every sentence adds value, a more concise version could remove some redundancy (e.g., the workflow repeats the tool names). Still, it earns a 4 for clarity and logical organization.

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

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

Given the tool's complexity (perception via accessibility tree) and the absence of an output schema, the description adequately covers the input parameters, output format (Markdown with stable IDs, JSON structure), and workflow integration. It could be improved by explicitly listing the Markdown format details, but overall it provides sufficient context for an agent to use the tool correctly.

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

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

Both parameters have 100% schema description coverage. The description adds significant value beyond the schema: for `semanticOnly`, it explains its purpose ('aggressively prunes non-interactive structural nodes') and use case ('large pages where you only need interactive elements'). For `format`, it details the JSON output structure (stableId, backendNodeId, role, name, value, childIds) and clarifies that it is the source of truth for the Markdown view.

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

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

The description clearly states the tool's purpose: it queries the browser's Accessibility Object Model via CDP and returns a hierarchical Markdown document (USAG). It emphasizes that it is 'THE PRIMARY PERCEPTION TOOL' and distinguishes itself from sibling tools by outlining a workflow where this tool is used first, followed by atomic_interact and get_state_delta.

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 includes a 'WHY THIS EXISTS' section explaining the rationale and a 'WORKFLOW' section that tells the agent when to use this tool (first step in perceiving a page) and how to use its output (backendNodeIds with atomic_interact). It implicitly warns against using raw HTML by stating it has 90% semantic noise, but does not explicitly exclude other tools or mention specific when-not scenarios.

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?

Despite no annotations, the description fully discloses the tool's behavior by enumerating all included telemetry categories (network, console, DOM, interactions, CLS, alerts). Notes that output is token-efficient, implying low overhead.

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?

Well-structured with bolded lead sentence, bullet list of contents, and a numbered workflow. Slightly verbose but all content is relevant and aids quick comprehension.

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?

Comprehensively covers what the tool returns and how to use it within a larger workflow. No output schema exists, but the description detail compensates fully.

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?

No parameters exist; schema coverage is 100% by default. Description correctly implies no input needed, adding no conflicting or redundant info.

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?

Clearly states the primary observability entry point and returns a token-efficient JSON summary of all telemetry. Distinguishes from sibling tool query_session_telemetry by positioning get_session_summary as the initial scan step.

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

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

Explicitly provides a progressive disclosure workflow: call get_session_summary first, then drill down with query_session_telemetry if alerts are triggered. Includes directive to never dump all logs/network at once.

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 fully discloses behavior: it computes delta, returns only added/removed/modified, and returns null if no changes. It also explains transient changes like toast notifications. This is comprehensive.

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

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

The description is well-structured with bold headings and bullet points for return types and examples. It is slightly verbose but every sentence adds value, and the use of examples enhances clarity.

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 output schema, the description fully explains the return structure (added, removed, modified, null) and provides concrete use cases. It is complete for the tool's purpose.

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

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

The tool has no parameters (schema coverage 100%), so the baseline is 4. The description does not need to add parameter details; it correctly focuses on the tool's purpose and output.

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 computes a structural delta between current page state and last checkpoint, returning only added, removed, modified nodes. It distinguishes from siblings like browser_state_diff and get_semantic_surface by focusing on differential streaming.

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 use this tool after every action and lists concrete scenarios (modals, spinners, button labels, toasts). It does not explicitly state when not to use or name alternatives, but usage 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?

The description discloses the return value ('pong') and condition (server healthy/ready). With no annotations provided, this is sufficient transparency for a simple health-check 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, front-loaded with the purpose, no unnecessary words. Every sentence adds value.

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

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

Despite no output schema, the description fully explains the return value. For a trivial tool, this is complete.

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

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

There are zero parameters, so the description adds no parameter details. Schema coverage is 100%, and the baseline for 0-parameter tools is 4.

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

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

The description clearly states the tool's purpose: to verify connection to the server and returns 'pong' if healthy. It uses a specific verb ('verify connection') and resource ('Best Browser MCP server'), distinguishing it from all sibling tools which perform browser operations.

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 explicit guidance on when to use this tool versus alternatives. While it's intuitive that ping should be used before other commands to check server health, the description does not provide that advice or mention any 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?

Despite no annotations, the description discloses it is a read operation that retrieves telemetry data without side effects. It mentions it avoids flooding context, but lacks details on authorization, rate limits, or data retention.

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?

Description is concise, well-structured with categories and examples. Front-loaded purpose, every sentence adds value, 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?

No output schema, but description provides sufficient detail for correct invocation. However, it does not describe the return format or pagination. Contextually complete for the tool's 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 has 100% coverage, but the description adds significant value by explaining valid filter values per category, providing concrete examples and enhancing understanding beyond 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 is for progressive disclosure drill-down to extract specific failing events after get_session_summary flags errors. It distinguishes itself from siblings like get_session_summary by focusing on surgical extraction.

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 states when to use: after get_session_summary flags errors. Provides categories and filters with examples, guiding the agent on how to use it 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?

The description discloses that it closes existing browser sessions, opens a new headful instance, and that the Black Box flight recorder captures all interactions. With no annotations available, this fully informs the agent of 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?

The description is well-structured with a bold lead sentence and a numbered workflow. Every sentence adds value, though it is somewhat lengthy; it could be slightly more concise.

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

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

Despite lacking an output schema, the description fully explains the tool's purpose, workflow, and side effects. It covers all necessary context for an agent to decide when and how to use 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?

The only parameter 'url' is described in the schema as 'URL to navigate to when the browser opens'. The tool description adds no additional semantic value beyond that, and schema coverage is 100%, 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 'HUMAN DEVELOPER TAKEOVER' and explains it pauses automation to open a visible browser for human interaction. This distinguishes it from sibling tools like browser_launch or browser_new_tab.

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 step-by-step workflow (1-4) and notes it closes any existing session. However, it does not explicitly mention when not to use it or compare to alternatives among siblings.

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

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

The description discloses key behaviors: it 'closes the browser' and returns a detailed timeline of events. This adds significant context beyond the name, though it does not cover edge cases like idempotency or handling of non-existent recordings.

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-loading the primary action and return value. Every sentence adds value 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?

Given no parameters and no output schema, the description adequately covers what the tool does and what it returns. It lacks prerequisites (recording must be active) but is otherwise complete for 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?

There are no parameters, so the description does not need to add param info. Baseline 4 applies as per guidelines.

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 stops the active human recording session and returns a synchronized timeline. It distinguishes from siblings by focusing on 'human recording' but does not explicitly differentiate from similar tools like browser_stop_recording.

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 suggests using get_session_summary and query_session_telemetry after stopping, but does not specify when to use this tool versus alternatives (e.g., browser_stop_recording) or provide exclusion criteria.

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 must fully disclose behavior. It does disclose that the tool is non-blocking, runs continuously at 60% JPEG quality, and returns the latest frame as base64 JPEG. However, it does not mention prerequisites (e.g., if a screencast session must be started first) or potential side effects like memory usage. With no annotations, the description is good but not fully explicit.

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

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

The description is concise with no unnecessary text. It front-loads the key behavior in the first sentence, then bullets use cases. Every sentence adds value, and the structure is clean.

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 has zero parameters, no output schema, and no annotations, the description is relatively complete. It covers purpose, behavior, use cases, and return format. Missing is explicit mention of the need for an active screencast session, but the sibling tool 'browser_start_recording' suggests this context is available, so it's not a critical 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?

There are no parameters (schema coverage 100%), so according to guidelines the baseline is 4. The description explains the output (base64 JPEG) but does not need to add param semantics since there are none.

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

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

The description clearly states it is a non-blocking visual capture that returns the latest frame from a screencast stream. It distinguishes itself from browser_screenshot by explicitly saying it does NOT block the browser's main thread or force a synchronous render, which helps an agent differentiate between the two tools.

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

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

The description provides explicit use cases (visual verification after action without blocking, Canvas/WebGL where AX tree is empty, monitoring animations/transitions) and directly contrasts with browser_screenshot, telling the agent when NOT to use this tool. This satisfies the highest level of guideline clarity.

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 fully handles transparency. It details all return cases: valid, occluded with selector, or invisible. No contradictions or omissions.