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

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses the effect: bringing the tab to the foreground and focusing its window, including the re-raise scenario. It does not discuss error cases or prerequisites, but for this simple focus operation the core behavior is transparent.

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

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

Two concise sentences with no filler. The primary behavior is front-loaded, followed immediately by actionable usage guidance.

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

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

The tool is simple and the description covers purpose and usage well, but it omits the meaning of the optional session_id parameter and any behavior when no session is provided. Since there are no annotations, this missing parameter context is a real gap, though the overall definition is still quite usable.

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 0%, and the description does not mention session_id at all. Although the parameter name and title give some hint, the description fails to explain how session_id identifies the tab or what passing null/default means, so the agent is left to infer this from context.

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

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

The description states a specific verb and resource: 'Bring a tab to the foreground and focus its window.' It also differentiates the tool from switch_tab by explaining that activation is for foreground work or re-raising a tab the user clicked away from.

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 when to use this tool: after switch_tab when foreground work is required, or to re-raise a tab. This gives an agent a clear decision rule and implicitly identifies switch_tab as the alternative for non-foreground tab changes.

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 usefully discloses prerequisites (target enabled and externally_connectable) and the no-tabs-open behavior. However, it does not explain what happens on failure, whether a response from the target is returned, or whether the message is fire-and-forget, which are important behavioral traits for an agent invoking this tool.

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

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

The description is three short sentences with no filler. The main action is front-loaded, followed by necessary target prerequisites and a useful operational note about tabs. Every sentence earns its place.

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

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

For a tool with only three parameters and an output schema, the description covers the core invocation context: the source, the target requirements, and the fact that no tab context is needed. The main gap is the lack of explicit failure/response semantics, which prevents a perfect score, but the essential information for a correct call is present.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly maps extension_id to the target extension and message_json to the JSON message payload, but it leaves session_id entirely unexplained and does not clarify the expected JSON string format or any encoding requirements.

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

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

The description states a specific action ('Send a JSON message') with a precise resource ('from the BTAP extension service worker to another installed extension'). This clearly distinguishes call_extension from sibling tools such as list_extensions or set_extension_enabled, which manage extensions rather than message them.

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

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

The description gives clear usage context: the target must be enabled and must declare the BTAP extension in externally_connectable, and the tool works without any tabs open. It does not name explicit alternatives, but there is no closely competing sibling tool for sending extension-to-extension messages, so the practical usage boundary is clear.

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

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

With no annotations, the description carries the full burden and delivers well: it details the return as text metadata plus MCP image content, clarifies save_path only adds a disk copy, explains return_base64 is opt-in, and specifies that width/height/left/top are physical screen pixels matching mouse_click's coordinate range unscaled. This is substantive behavioral context beyond a one-line summary.

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

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

Every sentence adds value: the primary behavior, the non-page-screenshot distinction, parameter side effects, and the critical coordinate-system note for pixel mapping. It is dense but efficient, with no filler.

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

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

No output schema exists, so the description explaining the returned metadata and MCP image content is essential and provided. It also covers save behavior, base64 opt-in, and coordinate semantics, making the tool fully usable by an agent without external assumptions.

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 0%, so the description must compensate. It clarifies save_path's side effect ('only adds a disk copy') and return_base64's opt-in nature. These add meaning beyond the raw schema. The description does not fully elaborate return_base64's output format, but for two simple optional params this is adequate compensation.

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

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

The description states a precise verb and resource: capture the complete visible virtual desktop across all displays and return text metadata plus MCP image content. It also explicitly distinguishes itself from a background-tab screenshot, which separates it clearly from capture_page_screenshot.

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 makes the scope explicit ('complete visible virtual desktop across all displays') and provides an exclusion ('this is not a background-tab screenshot'), which tells the agent when not to use this tool. It does not name an alternative tool directly, but the intended usage is clear enough from the scope and the sibling list.

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

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

With no annotations, the description carries the full burden and succeeds exceptionally. It discloses that the MCP image is attached even when save_path is set, that width/height are device pixels rather than CSS pixels, that `size` is the byte count, that base64 appears only when return_base64=true, and that the model may not have actually seen the pixels if it cannot consume images. These are exactly the non-obvious behaviors that would cause agent misuse.

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?

Five dense sentences, each earning its place: purpose, return behavior, unit warning, fallback routing, and base64 condition. The core action is front-loaded, and there is zero filler. The length is justified given 9 undocumented parameters and no annotations; every clause prevents a distinct misunderstanding.

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 complexity (9 optional params, 0% schema coverage, no annotations, no output schema), the description covers the critical operational facts: return shape, save_path semantics, pixel-unit trap, conditional output, and image-consumption fallback. Remaining gaps are minor — it does not clarify how tab_id/session_id select the target when omitted, nor valid format/quality value ranges — but these are largely inferred from names and defaults.

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 0%, so the description must compensate, and it does for the most error-prone parameters: save_path (controls only disk output), return_base64 (the sole switch for base64), format/quality (optional JPEG/WebP), full_page and clip (scoping modes), and the unit semantics of image dimensions. It does not address tab_id, session_id, or timeout behavior, but the critical traps are covered, which 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 lead sentence states a specific verb and resource: 'Capture a viewport, full-page, or clipped screenshot of a page/tab via CDP'. This distinguishes it from capture_desktop_screenshot (desktop vs page/tab), save_pdf (document vs image output), and scan_page (which is explicitly named as an alternative, not a screenshot tool). The scope, method, and format options are all identifiable without opening the schema.

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

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

The description gives explicit when-not-to-use guidance with named alternatives: 'If the current model cannot consume images, it has not seen the pixels and must use scan_page, execute_js, a page-specific API, or OCR instead.' This is a clear exclusion with concrete fallback tools. It does not explicitly contrast capture_desktop_screenshot or state positive selection criteria ('use this when you need page pixels'), though the first sentence implies it, so a 4 rather than 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 of behavioral disclosure. It says the tool 'runs' a command but does not mention side effects, safety risks, session requirements, or what happens on execution. For a raw CDP command execution tool, this is a significant transparency gap.

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

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

The description is a single sentence with no filler, and the core instruction is front-loaded. It earns its place, though it is terse to the point of under-specification.

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 that executes CDP bridge commands, the description is incomplete. It lacks usage context, behavioral caveats, and parameter detail. The output schema reduces the need to document return values, but the remaining gaps are material, especially with no annotations.

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 0%, so the description must compensate. It does clarify that batch_json is a full JSON command object passed as text, but it gives no structure or example, and it entirely ignores session_id. This is only minimal compensation for a required parameter with no other documentation.

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 verb 'Run' and resource 'CDP bridge batch command' identify the basic action, and the word 'batch' loosely distinguishes it from the sibling cdp_command. However, 'CDP bridge batch command' is jargon and is not explained, so an agent cannot reliably infer what a batch command actually contains or how it differs from the single-command sibling.

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

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

The description gives no guidance on when to use this tool versus cdp_command or any other sibling. The phrase 'CDP bridge batch command' vaguely implies a batch context, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It only states that the tool makes a single CDP call and describes two ID parameter formats; it does not mention side effects, error behavior, permissions, or whether the call mutates browser state. This is a significant gap for a generic command executor.

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 short sentences with the main action front-loaded. The second sentence adds relevant parameter format details, and there is no verbosity or repetition.

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

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

Although an output schema exists, the tool has 7 parameters, no annotations, and no schema descriptions. The description lacks guidance on which targeting parameter to use (session_id vs tab_id vs target_id), what timeout semantics are, and when to use this tool versus cdp_batch. These gaps make it insufficient for a complex command-invocation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that session_id accepts a 'client:tabId' composite and tab_id accepts a native number or that same composite string. However, it leaves method, params_json, timeout, target_id, and extension_id without any semantic explanation, so coverage is incomplete.

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

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

The description states a specific action ('Call') on a specific resource ('one Chrome DevTools Protocol command'), clearly distinguishing it from the sibling cdp_batch (batch execution). The purpose is unambiguous and immediately recognizable.

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

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

No guidance is provided on when to prefer this tool over alternatives such as cdp_batch or debugger_targets. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer suitability from the tool name alone.

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

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

With no annotations present, the description carries the full behavioral burden and does so thoroughly: it warns that identifiers must belong to the same browser, that lifecycle generations are checked before removal, and that the ownership bypass flag is reserved for explicit operator requests. These are non-obvious behaviors that substantially affect call success and safety.

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 dense sentences cover purpose, multi-tab constraints, ownership rules, and the special flag condition with zero filler. The most important action and identifier forms are front-loaded, and each sentence contributes new, necessary 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 moderate complexity (multiple parameter combinations, ownership nuance) and the presence of an output schema, the description covers all decision-relevant aspects: what identifiers are accepted, the same-browser constraint, the default ownership guard, and the escape hatch for operator-requested closures. Nothing an agent needs to know before calling is missing.

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

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

Schema description coverage is 0%, so the description must explain parameters on its own. It clarifies that tab_id can be a single identifier or a list, that session_id is an alternative composite identifier, that owner_id is required by default, and that only_if_agent_owned controls whether user tabs may be closed. This adds meaning far beyond the raw schema types.

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

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

The description opens with a specific verb and resource: 'Close one or more tabs by native tab id or composite session_id.' It precisely defines what the tool acts on and the two accepted identifier forms, making its purpose unmistakable even before reading the schema.

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

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

It explicitly explains the default ownership restriction ('closes only tabs created by this MCP task'), the requirement for owner_id, and the exact condition for using only_if_agent_owned=false ('only for an explicit operator request'). This tells the agent when it is safe to use the tool and when not to, without needing to infer policy.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose meaningful traits: the capture is bounded, it runs on a real-browser tab, and it does not foreground the tab. However, it does not explain what 'bounded' means in terms of timeout/max_entries, whether capture starts fresh, or any side effects on the tab.

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

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

Two sentences with no filler. The key behavior is front-loaded, and the follow-up tools are named immediately. Every part of the description 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 start/read/stop lifecycle is covered, and an output schema exists so return-value details are not strictly required. However, with no annotations and zero parameter documentation, the description leaves the meanings of timeout, session_id, and max_entries underspecified, which is a real gap for correct 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?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention timeout, session_id, or max_entries at all. The phrase 'bounded' hints at timeout/max_entries, but no concrete parameter meaning is provided, leaving the agent to rely on parameter names alone.

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

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

The description uses a specific verb and resource: 'Start a bounded Runtime console and exception capture on a real-browser tab.' It clearly distinguishes this start action from sibling tools like get_console_messages and console_capture_stop by naming the capture lifecycle phase.

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

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

The description gives explicit process guidance: use get_console_messages while running and console_capture_stop when done. It does not explicitly list alternatives or when-not-to-use cases, but the workflow context is clear enough for an agent to understand the tool's place in the lifecycle.

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 behavioral burden. It does disclose meaningful side effects: stopping capture, returning the buffer, and releasing a debugger lease. However, it does not explain what happens when no capture is active, whether the operation is idempotent, or what releasing the debugger lease implies for other debugging activity.

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 concise sentence front-loads the action and states the main effects in order. There is no filler, and every phrase adds 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?

The core purpose and major side effect are clear, and the presence of an output schema reduces the need to describe return values. Still, the description is incomplete because it omits clarification of the two parameters and provides no explicit guidance for selecting this tool over related capture/debugger 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?

Schema description coverage is 0%, and the description does not mention either timeout or session_id. The agent receives no guidance on what session_id refers to, why it can be null, or what the timeout controls, so it cannot reliably decide how to set these parameters.

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

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

The description names a specific verb and resource: 'Stop console capture on a real-browser tab'. It also lists the concrete effects—returning the remaining bounded message buffer and releasing the debugger lease—which clearly distinguishes it from sibling tools like console_capture_start and network_capture_stop.

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 it is the stop counterpart to console_capture_start, but does not explicitly state when to use it, what conditions require a session_id, or how it differs from get_console_messages for retrieving captured messages. Usage context is present only by implication.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains the dual behavior (bookmark vs folder), the optional parent behavior, and the default-location fallback. It does not mention duplicate behavior or permission requirements, but the core mutation semantics are clear and non-contradictory.

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

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

The description is two sentences with no filler. The primary action and key conditional rule are front-loaded, and every phrase adds behavioral or parameter value. It is appropriately sized for the tool's 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?

For a 4-parameter tool with no annotations, the description covers the main call-shaping decisions: required title, url conditionality, and parent default. The only clear gap is session_id, whose purpose is left unexplained, and the output schema presumably covers return values. Overall it is nearly complete for correct 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?

Schema description coverage is 0%, so the description must compensate. It explains url (presence determines bookmark vs folder) and parent_id (default Chrome location), but it does not explain session_id at all, and title's role as the bookmark/folder name is only implicit. The description adds meaningful semantics for some parameters but leaves a notable gap.

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

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

The description states a specific action ('Create a bookmark or folder') on a clear resource, and immediately disambiguates the two modes using the presence/absence of url. This distinguishes it from siblings like get_bookmarks and remove_bookmark without needing to inspect their schemas.

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

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

The description gives clear conditional usage guidance: supply url for a bookmark, omit url for a folder, and omit parent_id to use Chrome's default location. It does not explicitly discuss alternatives or when-not-to-use, but the conditions are specific enough for an agent to select and invoke the tool correctly.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It does so by clarifying the operation is a read-only listing, the scope includes hidden CDP targets, and the tool works even with zero tabs open. It does not explain session_id effects, but output schema existence reduces the need to describe return values.

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 short sentences, with the core verb and resource front-loaded. Every phrase earns its place: the target scope, the excluded alternative, and the no-tabs capability are all conveyed without repetition or filler.

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

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

For a low-complexity listing tool with an output schema, the description covers the main behavior and a key edge case. However, it leaves the optional session_id parameter unexplained and does not clarify how this relates to the sibling list_all_tabs tool, which creates a meaningful gap for correct 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?

Schema description coverage is 0% and the description adds nothing about the optional session_id parameter. The parameter name and title give some hint, but the description does not compensate for the missing schema documentation, leaving an agent to guess what session_id means and when to provide it.

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

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

The description uses a specific verb ('List') and resource ('every CDP-attachable target'), and goes further by naming examples (service workers, extension background pages). It also explicitly distinguishes itself from list_tabs, so an agent can immediately understand what unique capability this tool provides.

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

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

The description gives clear context for when this tool is valuable: when targets like service workers and extension background pages are needed, and when no tabs are open. It names list_tabs as the alternative that misses these targets, though it does not explicitly discuss exclusions or compare against list_all_tabs.

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

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

With no annotations, the description carries the full behavioral burden and does well: it reveals the operation targets the persistent 'real browser profile' rather than ephemeral state, and discloses the mechanism — CDP Network.deleteCookies with a document.cookie expiration fallback. This gives the agent meaningful expectations about side effects and reliability that the schema cannot.

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, all load-bearing: purpose, scope behavior, and mechanism/fallback. The core action is front-loaded and there is zero filler.

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

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

The output schema relieves the description of explaining return values, and core delete behavior plus scope targeting are covered. But for a tool with 7 parameters, no annotations, and 0% schema parameter coverage, leaving tab_id, timeout, and session_id unexplained is a noticeable gap.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for the scope parameters (url/domain/path and the current-page default), but tab_id, timeout, and session_id are never mentioned, leaving their semantics entirely undocumented. This is only partial compensation for a 7-parameter tool.

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

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

The description opens with a specific verb and resource — 'Delete a cookie by name from the real browser profile' — and adds scope semantics (defaults to current page, or pass domain/path/url). This inherently distinguishes it from cookie siblings like get_cookies and set_cookies, whose actions are clearly different.

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 scoping sentence gives actionable context ('pass domain/path/url to target another scope'), so an agent understands how to direct the deletion. However, there is no explicit when-to-use guidance or exclusion — nothing names alternatives or warns against using this when the document.cookie fallback would be ineffective, such as with httpOnly cookies.

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 behavioral disclosure burden and succeeds. It reveals session/cookie usage, default waiting behavior, file move semantics, no-replacement unless overwrite=true, timeout fallback behavior, and session_id constraints.

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

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

The description is five dense sentences with the core purpose front-loaded. Every sentence adds new behavioral or parameter information, with no filler or redundancy.

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

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

Given seven parameters, no annotations, and no per-parameter schema descriptions, the description covers most invocation-relevant behavior, including timeout edge cases and session requirements. It is slightly incomplete only on filename semantics and what happens when wait=false, but the presence of an output schema reduces the need to document return values.

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 0%, so the description adds meaning for most parameters: directory, overwrite, wait, timeout, session_id, and url. However, filename's role is not explained, leaving a gap in an otherwise strong parameter-semantics pass.

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

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

The description states a specific action—'Download an http(s) URL through the real browser's native download manager'—and clearly identifies the expected result: the final absolute local path. It also distinguishes the tool from a plain fetch by emphasizing that the browser profile's cookies and authenticated session are used.

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 'Use this for attachments instead of page fetch,' giving a concrete when-to-use rule and naming an alternative. It also communicates an important usage constraint: an explicit session_id must still be live and is never replaced with another profile.

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

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

With no annotations, the description carries the full transparency burden and meets it richly: it discloses the single total deadline, per-session pinning of all roundtrips, the route-first-then-fallback execution path, no retargeting on fallback, and precise retry semantics ('retries only proven-undelivered work, never an acknowledged script whose side effects may already have run'). These are non-obvious behaviors an agent needs to anticipate how the tool acts at runtime.

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

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

Three sentences, each earning its place: purpose+deadline, execution mechanism+fallback, and usage guidance+retry semantics. The core action is front-loaded in sentence one, and there is no filler or repetition of schema content.

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

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

Given the tool's complexity plus an output schema that documents return values and zero annotations, the description covers the essential behavioral surface: deadline, routing, fallback, and retry semantics. The gaps are no_monitor and dialog_policy semantics (especially relevant since arbitrary JS can trigger browser dialogs), which an agent would need to infer from parameter names alone.

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 0%, so the description must compensate. It does add meaning to some params: 'one total deadline' clarifies timeout semantics, 'pins every monitor/retry/result roundtrip to an explicit session' clarifies session_id, and the wait guidance shapes how script should be written. However, no_monitor and dialog_policy receive no explanatory text, leaving their behavior to inference from names and defaults.

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 opening phrase 'Execute arbitrary JS in the requested real-browser tab under one total deadline' names a specific verb, resource, and scope constraint. The fallback detail ('falls back to directed Runtime.evaluate') further differentiates it from raw CDP siblings like cdp_command/cdp_batch, so an agent can disambiguate without opening schemas.

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

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

Gives an explicit alternative with a when-not: 'Use wait_for/wait_for_url instead of setTimeout or sleep Promises', which prevents agents from embedding naive waits in scripts. The retry-semantics sentence also guides expectations about side effects. However, it never directly addresses when to prefer execute_js over sibling tools like cdp_command for JS evaluation, leaving some decision-making implicit.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly implies a read-only filesystem lookup returning a path, with no side effects. It doesn't elaborate on failure modes or prerequisites, but the simple nature of the operation makes the description 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?

The description is a single focused sentence that front-loads the action and resource. Every word contributes: 'Get absolute path', 'unpacked Chrome extension directory', and 'for manual installation' all add necessary information without redundancy.

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

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

For a zero-parameter helper that returns a filesystem path, the description is complete. An agent can correctly invoke it without further details, especially since the output format is covered by an output schema.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify about parameters. Following the baseline guidance for zero-parameter tools, a 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 uses a specific verb ('Get'), a precise resource ('absolute path to the unpacked Chrome extension directory'), and an explicit purpose ('for manual installation'). This clearly distinguishes it from extension-management siblings like list_extensions, set_extension_enabled, and uninstall_extension.

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 phrase 'for manual installation' gives clear context for when this tool is useful. It does not explicitly state alternatives or exclusions, but for a zero-parameter path-lookup tool the situational cue is sufficient. A 5 would require explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the meaning of the two returned profile states and their operational differences (elicitation skipping, approval requirements). It does not fully define terms like 'elicitation' or 'permission allow,' but it provides meaningful transparency for a zero-parameter getter.

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 the primary purpose front-loaded and no filler. The first sentence states exactly what is returned; the second packs the essential safe/lab semantics without redundancy.

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

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

For a simple read-only getter with no parameters and an output schema present, the description is complete: it states what is returned, the default mode, and the behavioral distinction between safe and lab. Nothing needed to invoke the tool correctly is missing.

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

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

The tool has zero parameters and the schema confirms an empty argument object, so there is no parameter behavior to describe. Per the zero-parameter baseline, the description earns a 4 by adding profile context rather than needing to explain inputs.

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

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

The description opens with a specific verb and resource: 'Return the active safe/lab automation profile.' It clearly identifies the tool as a getter for the current automation profile and distinguishes it from set_automation_profile via 'return active' versus setting. It also defines the two profile modes, removing ambiguity.

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

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

The description gives clear context for when this tool matters: lab is default and skips elicitation, while safe requires approval for physical actions. It implies the tool is used to read the current profile before deciding behavior, though it does not explicitly name alternatives or exclusions.

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

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

There are no annotations, so the description bears the full burden of disclosing behavior. It mentions one useful property (works with no tabs open) but does not explicitly state that this is a read-only operation with no side effects, nor does it describe behavior around the optional session_id or failure modes.

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 short, dense sentences with no filler. The core purpose is front-loaded, and the extra tab-context sentence earns its place by clarifying availability.

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 getter with an output schema, the description is minimally viable: it states the return object and an availability condition. However, it omits any clarification of session_id semantics and does not explicitly state the tool is read-only, leaving minor but real gaps for an agent to resolve.

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 0%, and the description does not mention the session_id parameter at all. The name 'session_id' is somewhat self-explanatory, but the description adds no meaning about whether it is required, what it selects, or how it affects the returned bookmark tree.

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 ('Return') and resource ('the browser bookmark tree'). This is easily distinguished from sibling tools like create_bookmark and remove_bookmark, which mutate bookmarks rather than read them. The additional note about working with no tabs open reinforces the scope.

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

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

'Works with no tabs open' implies the tool can be used independently of tab state, which provides some usage context. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisites beyond the tab note.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It transparently states that clear=true clears the full buffer after reading, and that filter='user' excludes extension service-worker/content-script logs. This goes beyond the schema and reveals meaningful side effects and filtering behavior.

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

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

The description is two sentences and free of fluff. It front-loads the core purpose and then packs high-value parameter guidance into the remaining sentence. Every clause contributes useful information.

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

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

The description covers the core behavior and the two most behaviorally significant parameters, and an output schema exists, so return values need not be detailed. Still, for a six-parameter tool with no annotations, key execution details like session_id, offset, max_items, and timeout are not explained, leaving an agent to guess how pagination or multi-tab selection works.

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 description adds real meaning to clear and filter, which is valuable given the schema provides no descriptions. However, offset, timeout, max_items, and session_id are left entirely unexplained, and with 0% schema description coverage these parameters remain ambiguous. The description compensates for only a subset of the parameters.

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

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

The description opens with a specific verb and resource: 'Read a page of captured console messages and exceptions from a real-browser tab.' It clearly identifies the tool as a read/retrieval operation and distinguishes it from sibling capture controls like console_capture_start and console_capture_stop.

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

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

The description gives explicit context for when to use the tool: it reads previously captured console messages. It also provides actionable guidance for the clear and filter options, explaining exactly what each does. It does not explicitly name alternatives or when not to use it, but the 'captured' wording implies it is intended after capture has been started.

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 of behavioral disclosure. It only states that cookies are fetched; it does not mention whether any browser permissions are required, whether the extension bridge session needs to be active, whether the call is read-only, or what happens when no cookies exist. 'Get' implies a read operation, but key behavioral context is missing.

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 short sentence with no filler. The core action and scope are front-loaded, and the mention of 'via the Chrome extension bridge' adds relevant context. It is concise, though it sacrifices some helpful detail for brevity.

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 getter with an output schema available, the description provides enough to understand the primary purpose. However, it lacks guidance on session_id, usage boundaries relative to cookie-modifying tools, and behavioral details. It is adequate but has clear gaps; it is not fully self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for tab_id by distinguishing 'current page' from 'specified tab', but it never explains session_id, which remains entirely undocumented. The description only partially clarifies the parameter space.

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

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

The description identifies a clear action ('Get') and resource ('cookies') with a specific scope: current page or specified tab. It does not explicitly contrast with sibling tools like set_cookies or delete_cookies, but the read/write distinction is inferable from the verb, so it is not misleading.

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

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

There is no guidance on when to prefer this tool over alternatives or when not to use it. Sibling tools include set_cookies and delete_cookies, but the description never names them or explains the boundary between reading and modifying cookies. The implied usage is clear only from the verb 'get'.

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 transparency burden; 'Return...' clearly marks this as a read-only diagnostic operation, and it discloses what is included. It does not mention side effects or error behavior, but the output categories and read-only framing are sufficient for safe selection.

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 front-loads the action and packs the essential output categories into a compact, scannable list. There is no filler or repetition.

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

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

With no parameters and an output schema available, the description covers the essential selection information: what the tool does and what data it returns. The only modest gap is explicit differentiation from sibling status/diagnostic tools.

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

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

The input schema has zero parameters, so the baseline is 4; no parameter-level documentation is needed. The description correctly focuses on output semantics instead.

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

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

The description names a concrete action ('Return') and identifies the resource ('setup status') while enumerating five specific data categories: component versions, stale-build actions, extension path, bridge ports, and connection status. This goes well beyond a tautology and separates it from narrower sibling tools like extension_path.

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

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

The phrase 'for setup/diagnostics' gives a contextual signal of when to use the tool. However, it does not explicitly state when not to use it or name sibling alternatives for diagnostics-related status checks.

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

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

With no annotations, the description carries the full burden, and it does add some value by defining dismiss, accept, and manual, including that manual 'reports the dialog without choosing.' However, it does not disclose timeout behavior, what happens if no dialog is present, whether the call blocks, or how prompt_text is used. That leaves significant behavioral gaps for an unannotated tool.

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

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

Two sentences with the main verb-resource statement first and the action list second. Every sentence adds information, and the clarification of manual behavior is compact and useful. There is no filler or restatement of the tool name.

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

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

Despite having an output schema, the tool has four parameters and zero annotations, so the description must supply practical invocation context. It omits how the target tab is identified, what prompt_text is for, timeout semantics, and the content of a manual report beyond 'reports the dialog.' This is insufficient for correct invocation in edge cases such as prompt dialogs.

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 0%, so the description must compensate, but it only clarifies the required action parameter's possible values. The timeout, session_id, and prompt_text parameters are left entirely to their names and defaults, which is insufficient for an agent to know how to fill them correctly. The partial clarification of action is not enough coverage for four parameters.

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

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

The description states the tool's job with a specific verb and resource: it inspects or handles a JavaScript dialog on a tab. It also enumerates the action modes, making the purpose unambiguous. It doesn't explicitly position itself against the sibling resolve_leave_dialog, so it loses a point, but the core purpose is 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 gives no explicit when-to-use or when-not-to-use guidance and does not mention alternative dialog-related tools. The action semantics imply it is for dismissing, accepting, or reporting dialogs, but an agent is left to infer when to select this over something like resolve_leave_dialog. This is below the clear-context bar.

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 reveals the real-keyboard nature, approval behavior in safe mode, lab-mode prompting behavior, default browser tab foregrounding and verification, and the special desktop/native-UI case for activate_session='none'.

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 focused paragraph that front-loads the core purpose, then adds mode, focus, and session guidance. It is efficient, though the environment-variable detail (BROWSERTAP_LAB_NO_ELICIT) adds some verbosity.

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

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

Given the tool's complexity and the presence of an output schema, the description is nearly complete: it explains the key format, session targeting, focus behavior, approval modes, and the special desktop/native case. It could be slightly more explicit about what happens when no session_id is provided or what output an agent should expect, but the output schema likely covers the return shape.

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 0%, so the description must compensate. It adds meaningful semantics: plural key examples for keys_csv, an explicit recommendation for session_id when targeting browser input, and a clear constraint for activate_session='none'. It does not explain all possible session_id formats or the full range of activate_session values, but it covers the important guidance.

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

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

The description opens with a specific verb and resource: 'Send a hotkey chord ... via the real keyboard.' It includes concrete examples ('command,l', 'ctrl,shift,p') and clearly distinguishes this from mouse or text-input tools by emphasizing real-keyboard delivery.

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

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

The description provides clear context for when to use the tool, including safe-mode vs lab behavior and the advice to prefer an explicit session_id for browser input. It also gives an explicit exclusion for activate_session='none', but it does not name alternative sibling tools or state when not to use hotkey in favor of another input method.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains that chrome-extension:// pages never become sessions because content scripts cannot run there, that those tabs have no session id, and that the tool works even with no tabs open. These are meaningful behavioral details beyond a simple 'list' operation, though it does not discuss return structure, which is partially covered by the output schema.

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

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

The description is compact, front-loaded with the core purpose, and every sentence earns its place. It states the main action, then adds the critical exception and the alternative tool, and closes with an edge-case guarantee. There is no redundant or filler language.

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 list tool with an output schema, the description covers the important edge cases: extension pages are included, they lack session ids, and cdp_command is the correct driver for them. It also handles the empty-tabs case. The main completeness gap is the unexplained session_id parameter, but the tool has no required parameters and a default null, so the core invocation path remains clear.

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

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

The schema has one optional parameter, session_id, with 0% schema description coverage, so the description should explain it. The description mentions the concept of session ids but never explains what the session_id input parameter does or how it affects the call. An agent gets no parameter guidance beyond the schema's bare type/default information.

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

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

The description uses a specific verb and resource: 'List every open tab', and immediately distinguishes itself from the sibling tool list_tabs by noting it includes chrome-extension:// pages that list_tabs hides. This makes the tool's scope unmistakable and differentiates it from its closest sibling.

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

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

The description explicitly names list_tabs as the sibling that hides extension pages, making it clear when list_all_tabs is the more comprehensive choice. It also gives a concrete alternative for extension pages that have no session id: drive them with cdp_command(tab_id=...) instead. This is explicit when/alternative guidance.

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

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

No annotations are present, so the description carries the burden. It discloses a useful non-obvious trait (works with no tabs open) and the exact output fields, confirming it is a non-mutating listing operation. It stops short of stating session-related behavior or error conditions, but for a simple list tool this covers the essentials.

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

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

A single front-loaded sentence with no filler. Every clause ('List installed browser extensions', '(id, name, ...)', 'Works with no tabs open') adds distinct 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 enumeration tool with an output schema, the description covers the key purpose and a critical runtime precondition. The only missing contextual element is the meaning of session_id, which is already penalized under parameter semantics.

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

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

The schema has 0% description coverage for the single parameter, and the description does not mention session_id at all. Since session_id is optional with a default, the gap is minor, but the description adds no 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?

States a specific verb ('List') and resource ('installed browser extensions'), enumerating the returned fields (id, name, enabled, type, version). Clearly differentiated from siblings like set_extension_enabled and uninstall_extension by naming a read-only enumeration operation.

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

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

Provides clear operational context ('Works with no tabs open') that tells the agent when it can be invoked. Does not explicitly name alternatives or exclusion conditions, but the purpose is unambiguous enough that the usage 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 carries the full burden. It clearly signals a read-only listing operation, scopes the behavior to 'all connected browsers,' and adds valuable downstream context by saying the session id should be 'passed verbatim.' It does not discuss auth or edge cases, but the core behavior is transparent for a simple list 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?

One sentence front-loads the action and scope, then provides the two most operationally important output details: the browser field and the session id usage. No filler or redundancy.

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

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

For a zero-parameter list operation with an output schema, the description is essentially complete: it names scope and follow-up usage. The only notable gap is the unresolved ambiguity with list_all_tabs, but the tool call itself is fully specified.

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

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

The input schema has zero parameters, so there are no parameter meanings for the description to clarify. The description still adds useful context about the output fields, exceeding the baseline required for a no-parameter tool.

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

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

The description states a specific action ('List') and resource ('connected tabs across all connected browsers'), and describes key output fields. However, it does not differentiate this tool from the similarly named sibling list_all_tabs, so it stops short of full sibling clarity.

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?

Usage is implied: the tool is for listing tabs and obtaining session IDs to pass verbatim to other tools. There is no explicit when-to-use or when-not-to-use guidance, and no comparison with the alternative list_all_tabs.

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 zero annotations, the description carries the full burden and delivers richly: the scaled-display pitfall, refusal via coordinates_off_screen instead of clamping to an edge, tab-raising behavior with and without session_id, the approval foregrounding side effect, and the activate_session='none' special case. This is unusually thorough behavioral disclosure for a pointer 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?

Every sentence earns its place and the most critical fact (coordinate space) is front-loaded. However, five distinct topics are packed into a single unbroken paragraph, which slightly hurts scannability for an agent parsing the 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?

An output schema exists, so return values need no description. The genuinely complex facets — coordinate space, off-screen error behavior, session targeting, activation modes — are all covered. Small gaps remain: what null x/y means (both default to null) and what 'the quiet check' refers to, but neither blocks correct 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: x/y get their physical-pixel semantics, session_id gets its tab-raising role, and activate_session gets its special 'none' value. Button, clicks, and interval are left to their self-explanatory names and defaults, which is a minor gap given the zero-coverage 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?

States a specific verb and resource: clicking on the real desktop at absolute virtual-desktop coordinates. Explicitly distinguishes itself from page_click by naming the coordinate-space difference (physical screen pixels vs viewport CSS pixels), so an agent can tell the two apart without opening either schema.

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?

Names page_click as the alternative and the axis of differentiation (coordinate space, with devicePixelRatio scaling), giving an explicit when-not-to-use signal. Also provides concrete invocation guidance: pass the preferred session_id so the right tab is raised after the quiet check, and use activate_session='none' to click the desktop as-is.

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 behavioral burden and delivers: it discloses off-screen coordinate refusal, safe-mode approval behavior, lab session-approval conditions, quiet-input check, foregrounding/verification of the browser tab, and restrictions on activate_session. This is unusually 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?

Dense but efficient; the action and coordinate system are front-loaded, followed by validation and session behavior. Some sentences are long and packed with conditional details, making it slightly harder to scan, but every sentence adds operational 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?

Covers the critical invocation details for a physical-desktop drag: coordinate space, off-screen validation, approval behavior, and browser-session activation. The main gap is optional parameter semantics such as button and duration, but defaults and the presence of an output schema reduce the impact.

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 0%, so the description must compensate. It explains the coordinate parameters meaningfully and adds session-related semantics, but button and duration are left with only schema defaults and no description-level guidance.

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

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

States a precise verb+resource: "Drag the real mouse from one point to another" in absolute physical screen pixels. It also distinguishes itself from page_drag's CSS-pixel coordinate space, making its purpose clear relative to 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?

Provides clear context for when this tool is appropriate: physical screen pixels rather than CSS pixels, and it references page_drag as the differing alternative. It also gives concrete session guidance: prefer an explicit session_id for browser input and reserve activate_session='none' for desktop or native UI targets.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers: it explains off-screen coordinates are refused rather than clamped, safe-mode vs. lab approval behavior, and default browser-tab foregrounding/verification after the quiet-input check.

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 dense but every sentence contributes distinct information, with the most important coordinate-system distinction front-loaded. There is no filler or repetition of structured fields.

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 an output schema present, the description covers coordinate space, error handling, approval flow, session activation, and browser-tab behavior. Nothing critical for selecting and invoking the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It richly explains x/y physical-pixel semantics and the session_id/activate_session behaviors. However, the duration parameter is left entirely to inference, and its units are not specified.

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

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

The description opens with a precise verb and resource: 'Move the real mouse cursor to absolute virtual-desktop coordinates in PHYSICAL screen pixels.' It clearly differentiates this from related tools by stating the coordinate space differs from page_click and is shared with pointer_info and capture_desktop_screenshot.

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

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

The description gives explicit usage context: it names page_click as the CSS-pixel alternative, advises preferring an explicit session_id for browser input, and restricts activate_session='none' to intentional desktop/native-UI input. This tells an agent when and how to use the tool versus 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 burden of behavioral disclosure. It does this well by noting the capture is 'bounded', that the tab is not foregrounded, and that a debugger lease is released on stop. It could be more explicit about failure modes or what happens if a capture is already active, but the key side effects are disclosed.

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

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

The description is two sentences with no filler. It front-loads the main action and capture scope, then gives the essential lifecycle instruction in the second sentence.

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

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

The description clearly covers the core workflow and there is an output schema to describe return values, but with 6 optional parameters and zero schema descriptions, an agent still lacks guidance on how to tune the capture. The 'bounded' framing is vague about which limits apply, and no failure semantics are mentioned.

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 0%, so the description must compensate for the 6 undocumented parameters. It only hints at one parameter group, 'optionally response bodies' for include_bodies, and 'bounded' loosely suggests timeout/max_entries, but timeout, session_id, body_timeout, max_body_bytes, and max_entries are left unaddressed.

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

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

The description states a specific verb and resource: 'Start bounded CDP Network capture on a real-browser tab.' It also clarifies what is captured ('requests, responses, and optionally response bodies') and explicitly contrasts with the sibling stop tool by naming network_capture_stop.

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

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

The description gives clear context for when this tool is appropriate: capturing network traffic on a real-browser tab, and it explains the necessary follow-up call to network_capture_stop to retrieve the buffer and release the debugger lease. It does not explicitly discuss exclusions or compare against alternatives like console_capture_start or cdp_command, so it stops short of a 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses that the debugger lease is released, that returned records can be filtered, that url_pattern follows JavaScript RegExp syntax, and that invalid patterns produce a structured error. This is meaningful behavioral context beyond the schema, though it does not cover every edge case such as behavior when no capture is active.

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

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

The description is compact and front-loaded: the main action comes first, followed by optional filtering behavior and a key syntax detail. Every sentence contributes useful information without repetition or filler.

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

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

The description covers filtering semantics and error behavior, but for a 7-parameter tool with no annotations it omits crucial context around session_id and timeout. An agent would not know that session_id likely connects to a prior network_capture_start call or what passing null means. The presence of an output schema reduces the need to explain return values, but the invocation context remains incomplete.

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 0%, so the description must compensate. It successfully adds semantics for url_pattern, resource_type, status_min/status_max, and include_response_bodies by grouping them as filtering options. However, it does not explain session_id or timeout, which are less obvious and important for correct invocation.

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

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

The description states a specific verb and resource: 'Stop Network capture on a real-browser tab.' It also clarifies the related action of releasing the debugger lease, which distinguishes this tool from capture-start or console-capture tools. The mention of returned-record filtering makes the tool's scope unmistakable.

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

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

The stop action implies it is used after a network capture has been started, but the description never explicitly says 'use after network_capture_start' or contrasts it with console_capture_stop. The use-case context is inferable rather than stated, so it does not fully meet the explicit guidance bar.

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, and it does this well. It explains exactly-once creation, operation_id reconciliation after lost ACKs, the single-total-deadline guarantee, and the precise status/retry semantics before and after dispatch. This is unusually transparent for a tool description.

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 dense and front-loaded with the core purpose, followed by the most important semantic guarantees. While long, each sentence adds information; there is no filler. The repeated status tokens are slightly redundant but serve to make the retry contract explicit.

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 complex exactly-once and retry semantics, the description is nearly complete and covers the key edge cases an agent would worry about. It is missing explanations for several parameters, but an output schema exists, so return-value documentation is not required here.

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 0% description coverage, so the description must compensate by explaining parameters. It meaningfully elaborates only the active parameter (foreground vs background). The url, timeout, owner_id, and session_id parameters are not explained, and the description references an operation_id that does not appear in the input schema at all, which may confuse an agent.

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

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

The description clearly identifies a specific operation: opening one real-browser tab, with a background-by-default behavior and exactly-once creation semantics. It does not explicitly distinguish itself from sibling tools like open_url, but the verb-plus-resource statement is otherwise precise and unambiguous.

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

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

The description provides practical usage guidance: use active=true only when foreground work is genuinely required, and avoid URL-based guesses or unmarked create retries. It lacks an explicit comparison to alternative sibling tools, so it does not fully close the selection question, but the guidance given is concrete and operational.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that navigation happens through CDP, the window is not raised, and beforeunload handling defaults to dismiss with a lab-mode exception. It also exposes the escape hatches for controlling that behavior, which is valuable beyond the schema.

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

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

The description is compact and front-loaded: the core purpose is stated first, followed by the important behavioral caveat and the available control options. Every clause adds information, and there is no redundant filler.

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

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

An output schema exists, so return-value documentation is not required. The description covers the main action, the unusual no-window-raise behavior, and the nuanced beforeunload handling. It could be more complete by explicitly routing to alternatives like open_new_tab and clarifying session_id, but overall it provides enough context for correct 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?

Schema description coverage is 0%, so the description must compensate. It does meaningfully explain beforeunload and intent_leave, which are the most semantically tricky parameters. However, url, timeout, and session_id receive no explanation, leaving a partial gap for a five-parameter tool.

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

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

The description clearly states the action: navigate the current real-browser tab via CDP, without raising its window. It uses a specific verb and resource, and the phrase 'current real-browser tab' distinguishes it from sibling tools like open_new_tab or 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?

The description implies this tool operates on the existing current tab, which suggests it is for navigation rather than opening new tabs. However, it never explicitly contrasts it with open_new_tab or states when to choose this tool over alternatives. The 'use accept/manual/intent_leave' guidance concerns parameter behavior, not tool selection.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the tab is not activated, the desktop cursor does not move, ambiguous or unreachable targets dispatch nothing, selector mode is hit-tested with auto-scroll, and coordinate mode is not hit-tested. It also reveals the 'obscured', 'occluded_by', and 'outside_viewport' result semantics. There is no annotation contradiction.

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

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

The description is dense but logically organized: action first, then coordinate-space caveats, then behavioral guarantees. Every sentence carries a distinct operational fact and there is no filler. The long sentence structure could be easier to parse with bullets, but the information density justifies the length.

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 that an output schema exists and no annotations are present, the description covers the critical call semantics: target selection, coordinate systems, offsets, hit-testing, scrolling, and side effects. The only real gaps are generic parameter details like timeout units, button values, and the precise role of session_id in tab selection. For a complex 9-parameter tool with zero schema descriptions, this is close to complete but not entirely exhaustive.

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

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

The schema has 0% description coverage, so the description must compensate. It does for the most confusing parameters: x/y are viewport-relative CSS pixels, offsets are measured from the element's top-left corner, an omitted offset axis uses the center, and selector accepts CSS or structured locators. Less critical parameters such as button, clicks, timeout, and session_id are left to their names and defaults, making the compensation strong but not exhaustive.

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

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

The description opens with a specific verb-resource pair: click a CSS/structured locator or viewport coordinates in a specific real browser tab. It also distinguishes itself from siblings by contrasting background CDP input with the physical screen pixels used by mouse_click and the device pixels used by capture_page_screenshot. The purpose is immediately recognizable and hard to confuse with alternatives.

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 strong usage context: this is for in-page, viewport-relative clicking without activating the tab or moving the desktop cursor. It explicitly warns that mouse_click uses physical screen pixels and capture_page_screenshot uses device pixels, which tells the agent which coordinate spaces not to feed it. However, it does not provide a formal when-to-use/when-not-to-use decision rule beyond these coordinate caveats.

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 behavioral disclosure burden. It reveals that the drag uses one background CDP input sequence, does not activate the tab, does not move the desktop cursor, uses viewport-relative CSS pixels, and is not hit-tested. This is unusually rich behavioral detail beyond what the name or schema could convey.

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 with no filler. The main action is front-loaded, and every additional clause adds useful clarification about coordinate space, background execution, tab activation, cursor movement, and hit-testing.

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 core behavior and coordinate semantics are well covered, and the output schema reduces the need to explain return values. However, the description says 'in a specific tab' but never connects that tab selection to the session_id parameter, and optional parameters like button, timeout, and duration lack the detail needed to invoke non-default behavior correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies x1, y1, x2, and y2 as viewport-relative CSS pixels, but it leaves button, timeout, duration, and session_id semantically unexplained. The description does not define units for timeout/duration, allowed values for button, or how session_id selects the 'specific tab' mentioned in the 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 uses a specific verb and resource: 'Drag between viewport coordinates in a specific tab.' It actively distinguishes itself from mouse_drag by coordinate system and from page_click's coordinate mode, so an agent can tell exactly what this tool does without opening schemas.

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

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

The description provides clear context: this tool works in a background tab, does not activate the tab, and does not move the desktop cursor. It also contrasts with mouse_drag's physical screen pixels, giving an explicit alternative for choosing the right tool. It does not list formal when-to-use/when-not-to-use conditions beyond that, but the guidance is strong.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that input is sent via background CDP and that the tab is not activated, which are meaningful behavioral facts beyond the schema. It could add more about timing, failures, or whether modifiers are released, but the 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?

The entire description is one tightly worded sentence that front-loads the action and embeds the key constraints. There is no filler, and every phrase earns its place.

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

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

The description covers the tool's core behavior and there is an output schema, so return values need not be explained. However, without annotations, it lacks explicit guidance on when to choose this over sibling tools like hotkey or page_click, and it leaves two parameters semantically under-specified. It is minimally adequate but not 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 0%, so the description must compensate for all three parameters. It clarifies keys_csv by mentioning 'comma-delimited modifier chord', but timeout and session_id are not explained at all. The parameter names are self-descriptive, but the description adds only partial value for one of three parameters.

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

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

The description uses a specific verb ('press') and resource ('a specific tab'), and clearly distinguishes this tool from siblings by specifying 'background CDP input' and 'without activating the tab'. This makes its purpose unambiguous and differentiates it from hotkey or page_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?

The description implies when to use this tool: when a key or modifier chord must be sent to a specific tab without bringing it to the foreground. It does not explicitly name alternative tools or list exclusions, but the 'without activating the tab' qualifier provides clear contextual selection guidance.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the CDP-based input path, automatic xterm textarea retargeting, optional clear/submit behavior, and a no-op guarantee for missing, ambiguous, or unusable targets. This is substantial and goes well beyond the input schema, though it does not cover timeout behavior or possible error responses.

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

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

Two tightly written sentences with no filler. The core action and target are front-loaded, followed by a special-case note, optional behaviors, and the no-op outcome. Every clause earns its place.

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

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

The tool has six parameters and an output schema, and the description covers target selection, tab scoping, optional clear/submit, xterm handling, and failure behavior. It is slightly incomplete only in explaining timeout semantics and how selector objects are interpreted, but it is otherwise sufficient for correct 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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by mapping 'focused element' and 'CSS/structured-locator field' to the selector parameter, 'specific tab' to session_id, and 'clear and submit a key' to clear and submit_key. Only timeout is left under-described, but the core parameters are contextualized.

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 a concrete action ('Insert text'), a precise target ('focused element or a CSS/structured-locator field in a specific tab'), and a distinguishing mechanism ('background CDP input'). This separates it from siblings like type_text or page_press without needing to name them.

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

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

The description implies contexts such as xterm containers and structured-locator targets, but it never explicitly states when to use this tool over type_text or page_press. It provides useful situational details but leaves the comparison and exclusion rules to inference.

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

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

Since no annotations are provided, the description carries the full behavioral burden, and it delivers: it discloses that screen_width/screen_height cover only the primary display while screen_bounds spans the virtual desktop, and that output is in physical not CSS pixels. The verb 'Report' clearly signals a non-mutating query. It lacks only minor details like whether the position is sampled live or cached.

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

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

Three sentences with zero waste. The core purpose is front-loaded in the first sentence, the second sentence resolves the primary-vs-virtual display ambiguity, and the third sentence prevents a common unit confusion with page_* tools. 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 output schema documents return values, and there are no parameters, so the remaining burden is coordinate semantics—which the description fully addresses. It explains physical vs CSS pixels, primary vs virtual desktop, and the interaction with mouse_click's accepted range. Nothing an agent needs to correctly call and interpret this tool is missing.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description adds further value by explaining the semantics of the returned fields (screen_width/screen_height vs screen_bounds), which helps the agent interpret the output schema correctly even though no argument documentation 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?

States a specific verb (Report), resource (desktop mouse position and screen geometry), and the critical unit qualifier (PHYSICAL pixels). The distinction from page_* tools which use CSS pixels separates it from sibling tools that also deal with coordinates. An agent can immediately understand what this tool returns and how it differs from page-level coordinate tools.

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

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

The description explicitly excludes page_* tools as alternatives by noting they use CSS pixels, and tells the agent that screen_bounds is the range mouse_click will accept—implying pointer_info should be consulted before clicking. This provides clear context for when to use it, though it stops short of explicitly stating 'call this before mouse_move/mouse_click' or naming the exact alternative conditions.

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 recursive removal affects the full subtree, which is meaningful behavioral context. It does not mention irreversibility, prerequisites, failure behavior, or session requirements, which would be valuable for a destructive 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 short sentences with the primary action front-loaded and the one critical conditional detail following. There is no filler or redundant restatement.

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 core operation and the trickiest parameter behavior, and an output schema exists so return-value explanation is not required. It falls short only by omitting session_id and not stating the behavior when removing a folder without recursive=true, which are relevant for a destructive tool.

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

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

The description adds meaning beyond the schema for recursive ('only for a folder whose full subtree should be removed') and identifies bookmark_id as the target by id. However, schema description coverage is 0% and session_id is never mentioned, so parameter guidance is incomplete.

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

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

The description states a specific verb and resource: 'Remove a bookmark by id.' This clearly distinguishes it from sibling tools like get_bookmarks and create_bookmark, and the recursive note adds relevant scope.

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

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

It gives a useful conditional: 'Set recursive=true only for a folder whose full subtree should be removed,' which guides parameter usage. However, it does not explicitly mention alternatives or state when not to use this tool, so tool-selection context is only implied.

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

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

With no annotations provided, the description carries the behavioral burden. It states that the action restores temporary leases, affects the selected browser, and only accepts http/https origins. It could disclose side effects or irreversibility in more detail, but the core behavior is transparent.

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

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

Two sentences deliver the essential behavior, the conditional reset-all usage, and the origin scheme constraint. The description is compact, front-loaded, and every clause earns its place.

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

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

The description covers the main behavior and the crucial origin constraint, but it leaves session_id semantics and accepted permission values unspecified. The output schema helps with return expectations, yet the missing parameter context prevents full standalone completeness.

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 0%, so the description must compensate. It explains origin and permission usage, including the reset-all behavior when both are omitted, but it does not describe session_id at all or enumerate valid permission values. This is a meaningful gap.

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

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

The description uses a specific verb ('Restore') and resource ('temporary site-permission leases'), making the tool's function immediately clear. It also distinguishes this tool from siblings like set_site_permission by framing it as the reset counterpart.

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 concrete usage guidance: omit origin and permission to reset every lease for the selected browser, and restrict origin to http/https. It does not explicitly name alternatives or exclusions, but the context makes the all-vs-matching distinction 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 a bounded multi-step workflow, the condition for early return, and a lab-only fallback gated by physical-input approval. This goes well beyond the tool name, though it does not mention side effects of accepting the leave or what happens to the page afterward.

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

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

The description is compact and front-loaded with the purpose, then packs the entire workflow into one structured sentence. There is no filler, though the dense jargon and run-on structure make it harder to parse than necessary.

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 workflow branches are covered, and the output schema likely handles return values. However, the description omits any guidance on session_id and does not position this tool relative to handle_dialog, which is a meaningful gap for an agent deciding how to invoke it correctly.

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

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

Schema description coverage is 0%, and the single optional session_id parameter is never mentioned in the description. The description adds no meaning about what session_id represents or how it affects the workflow; with low coverage the description should compensate, and it does not.

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

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

The description states a specific verb and resource: 'Resolve an intended beforeunload leave.' It clearly targets a particular dialog workflow and distinguishes itself from the more generic handle_dialog sibling by naming 'beforeunload,' though it does not explicitly name the sibling.

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

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

The description implies when to use the tool: when an intended beforeunload leave needs resolving. It provides detailed internal conditions such as returning immediately when no dialog exists and using the fallback only when protocol handling fails, but it does not explain when to prefer this over handle_dialog or state exclusions.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does this well by revealing atomic file writes, validation of non-empty PDF bytes, and the CDP timeout behavior that invalidates and detaches the debugger lease.

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 dense sentences with no filler. Purpose is front-loaded, and every clause adds meaningful behavioral or safety 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?

While an output schema exists and the behavioral detail is strong, the tool has 8 parameters, no annotations, and no schema descriptions. Missing context includes prerequisites like an active tab or session, timeout units, and clearer guidance for optional parameters, so the description is not fully complete for correct 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?

Schema description coverage is 0%, and the description adds no parameter-level explanation for save_path, session_id, timeout units, page_ranges, or the other options. Parameter names and defaults provide some clues, but the description does not compensate for the low coverage.

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

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

The description uses a specific verb ('Print') with a clear target ('real-browser tab') and a specific output ('validated PDF file'). It is clearly distinct from sibling screenshot and download tools, even without naming them.

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

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

The intended use is implied: call this when you need to turn the current real-browser tab into a PDF. However, it does not explicitly mention when not to use it or name alternative tools, leaving some routing to inference.

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

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

With no annotations provided, the description carries the behavioral burden. It usefully indicates a read-only operation, that the real browser session/login state is preserved, and that output is simplified HTML/text with defaults and timeout. However, it does not disclose potential side effects, how extra_js is executed, or what 'simplified' means in terms of content fidelity.

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

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

The description is concise and front-loaded, with the primary purpose in the first sentence and defaults in the second. It avoids filler and repetitive content. It could earn a 5 if it used the remaining space to clarify parameter semantics, but as written it is efficient despite being under-specified elsewhere.

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 7 parameters, no annotations, and 0% schema description coverage, the description is not complete enough. The output schema covers return shape, but the many undocumented parameters and lack of usage guidance leave significant gaps. An agent cannot confidently decide when to use this tool or how to configure it beyond defaults.

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 0%, so the description must compensate, but it only restates defaults for three of seven parameters without explaining their meaning. Parameters like extra_js, text_only, session_id, and instruction remain completely unexplained. The description adds a few hints like 'timeout=15 seconds' but is far from sufficient for correct parameter use.

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