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

Annotations already indicate readOnly=false, destructiveHint=true, and idempotent=false. The description adds useful context about foregrounding and focusing, but it does not explain why the operation is marked destructive or what side effects may occur beyond bringing the tab forward. No contradiction with annotations, but the description does not enrich the destructive behavior disclosure.

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

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

The description is two concise sentences, front-loads the core behavior, and adds usage guidance without any filler. 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?

Given the simple single-parameter tool and existing output schema, the behavioral description is reasonably complete for the operation itself. However, the complete lack of session_id documentation leaves a hole in the agent's ability to call the tool correctly in multi-session contexts.

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% for the only parameter, session_id, and the description does not mention it at all. Since the description must compensate for the missing schema documentation, this is a significant gap: the agent receives no guidance on what session_id means or how to populate 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 clearly states a specific action ('Bring a tab to the foreground and focus its window') and names the tool's relationship to switch_tab. It is easy to distinguish from the sibling switch_tab tool by reading the description alone.

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

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

It explicitly tells the agent when to use this tool: after switch_tab when foreground work is required, or to re-raise a tab the user has clicked away from. This provides concrete usage conditions and an implicit contrast with the switch_tab alternative.

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

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

Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful context beyond annotations: the target must be enabled and configured for externally_connectable, and the operation works without any open tabs. It does not spell out side effects, but the output schema and annotations cover the safety profile.

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 no filler. It front-loads the core action, then supplies necessary prerequisite context without wasting words.

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

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

For a required call, the description provides the target extension, message content, and key prerequisites such as enabled status and externally_connectable configuration. The optional session_id parameter and failure behavior are not described, but the presence of an output schema reduces the burden on the description.

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?

With 0% schema description coverage, the description compensates for extension_id and message_json by identifying the target as 'another installed extension' and the payload as a 'JSON message.' However, session_id is not explained at all, leaving an optional parameter without semantic 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 states a specific verb and resource: 'Send a JSON message from the BTAP extension service worker to another installed extension.' It clearly distinguishes this from sibling tools like list_extensions or set_extension_enabled, which manage extension state rather than communicate with an 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 description gives explicit prerequisites for use: the target extension must be enabled and must list this BTAP extension in externally_connectable. It also notes that it 'Works with no tabs open,' providing clear context. It does not explicitly name an alternative or say when not to use it, though no direct sibling offers the same capability.

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

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

Despite annotations already marking the tool as destructive and non-idempotent, the description adds substantial behavioral detail: each attempt consumes its ticket, the action sends one bounded message without activating a window, cancellation is only reported after the HWND disappears, uncertain results are unknown with retry_safe=false, and failure reasons are enumerated.

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 front-loaded with the core capability and requirements. Most sentences add important operational detail, though a few clauses like "Explicit desktop capability" and the retry_safe phrasing add minor redundancy or ambiguity without much 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 destructive, non-idempotent desktop interaction tool, the description covers prerequisites, side effects, success criteria, failure modes, and post-action guidance. With an output schema present, it sufficiently covers what an agent needs to invoke the tool correctly.

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

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

Even though schema description coverage is 0%, the description explains that ticket must come from a fresh inspect_native_file_dialog call and that desktop_opt_in=true is required and consumed per attempt. It does not fully elaborate the format of ticket or behavior when desktop_opt_in is false, but it gives meaningful guidance for both 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: "cancel the Windows file dialog identified by a fresh inspect_native_file_dialog ticket." It clearly distinguishes this from siblings like inspect_native_file_dialog and handle_dialog by focusing on the cancel action and requiring a prior inspection ticket.

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: it requires desktop_opt_in=true, follows a safe/lab physical-approval policy, and requires a fresh ticket from inspect_native_file_dialog. It stops short of naming alternative tools for other dialog actions, so it lacks explicit when-not-to-use guidance, but the usage context 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?

The description adds substantial behavior beyond the annotations: an attached MCP image is always returned, base64 is only present when requested, image dimensions are device rather than CSS pixels, and size means byte count. These are non-obvious and prevent incorrect interpretation. It does not contradict the destructiveHint annotation; the save_path write behavior is acknowledged.

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

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

Four dense sentences, front-loaded with the core action and modifiers, then essential caveats. Every sentence adds distinct value, with no filler or repetition. The only minor jargon is 'page-specific API,' but it is acceptable in context.

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

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

For a 9-parameter tool with no output schema, the description covers the most critical pitfalls: output side-channel behavior, disk-writing semantics, pixel units, and model-image limitations. It leaves tab/session selection and timeout semantics implicit, but these are partially supported by sibling tools and self-explanatory 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?

With 0% schema description coverage, the description carries the burden for 9 parameters. It explains format/quality, full_page, clip, save_path, and return_base64, but leaves timeout, tab_id, and session_id semantics implicit. Some mentioned fields like image_width/image_height appear to describe return metadata rather than input parameters, so parameter coverage is partial.

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: 'Capture a viewport, full-page, or clipped screenshot of a page/tab via CDP.' It clearly enumerates the tool's modes and contrasts it with page_click on pixel semantics and with scan_page/execute_js on image-consumption limitations, so an agent can distinguish it from siblings.

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

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

It explicitly states when not to rely on the result: if the model cannot consume images, it has not seen the pixels and must use scan_page, execute_js, a page-specific API, or OCR instead. It also clarifies that save_path only controls disk output and the MCP image is still returned, preventing a likely misuse.

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

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

The annotations already mark destructiveHint=true, but the description dramatically expands on this: side effects across multiple targets or the entire profile, child target tabId inheritance, whole-batch policy checks before dispatch, exact blocked response fields (raw_cdp_blocked, delivery_state=undelivered, retry_safe=false, retryable=false), and the need to inspect state before retrying. This is rich behavioral context that far exceeds what annotations convey, with no contradiction.

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

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

The description is a single dense paragraph that front-loads the critical side-effect warning and then details policy, delivery, and retry behavior. While not broken into sections, every sentence adds value. It is lengthy but appropriate given the tool's complexity and risk profile.

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 destructive potential, the description thoroughly covers safety, policy enforcement, delivery states, and retry guidance. However, it omits parameter semantics (batch_json format, session_id purpose) and does not clarify the output schema's return values. Given the output schema exists, that may be acceptable, but the parameter gap makes the description incomplete for an agent attempting 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 carries full responsibility for explaining the parameters. It only mentions passing 'the full JSON object with cmd='batch'' for batch_json but does not elaborate on its structure, requirements, or format. session_id is entirely unaddressed. This is a significant gap for a tool with only two 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 never explicitly states the tool's core action (e.g., 'Send a batch of CDP commands'). It opens with a warning about side effects and later mentions passing a JSON object with cmd='batch', which implies the purpose but leaves it to inference. It does distinguish itself from siblings by focusing on batch behavior, but the primary function is not stated directly.

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 substantial operational guidance: how to invoke (cmd='batch'), the lab-mode requirement for high-risk methods, and the safe-mode blocking behavior. However, it does not explicitly state when to choose this tool over alternatives like cdp_command (e.g., 'use this for multiple commands in one atomic batch') or when not to use it. The guidance is more about safety constraints than decision-making between tools.

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

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

The description enriches the destructive/openWorld annotations with concrete guard behavior: high-risk methods are blocked unless mode=lab and BROWSERTAP_ALLOW_UNSAFE_CDP=1, with delivery_state=undelivered, retry_safe=false, and retryable=false. It also warns that even allowed CDP/JavaScript can mutate page or profile state and advises inspecting state after uncertain delivery. This goes well beyond the structured annotations.

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

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

The description is dense but efficient: the side-effect warning is front-loaded, followed by target selection, the iframe caveat, and the guard behavior. Every sentence carries a distinct safety or targeting fact, though the paragraph is longer than strictly 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?

For a dangerous raw-CDP tool, the description covers target selection, cross-process iframe handling, blocked-method guardrails, and retry behavior, while the output schema covers return details. Minor gaps remain around what a 'composite' tab_id means and how to structure params_json.

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?

With 0% schema description coverage, the description compensates partially by explaining the meanings of session_id, tab_id, extension_id, and target_id, and by explaining how to derive target_id for a cross-process iframe. It does not explain params_json formatting, timeout semantics, or valid method formats beyond the high-risk blocking note, so several parameters remain under-documented.

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 centers on dispatching raw CDP commands to a target and warns about side effects, so an agent can infer the tool's purpose. However, it never states an explicit verb like 'sends a CDP command' and does not distinguish itself from the sibling cdp_batch or execute_js tools.

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

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

It gives meaningful targeting guidance: choose deliberately among session_id, tab_id, extension_id, and target_id, and use target_id from DOM.describeNode.frameId for cross-process iframes. It does not state when to prefer this tool over alternatives like execute_js, cdp_batch, or page_click, and it gives no explicit exclusions.

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

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

Annotations already indicate destructive and non-idempotent behavior. The description adds crucial behavioral details: ownership checking (only closes agent-owned tabs by default), lifecycle generation checks before removal, and the need for owner_id. It also warns that bypassing the ownership flag requires explicit operator request, adding a safety dimension beyond the raw annotations. No contradiction with annotations.

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

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

The description is concise but dense, starting with the core purpose in the first sentence. It packs necessary constraints and flags without excessive verbosity. While it is longer than a one-liner, every sentence contributes critical information, making it efficient and well-structured.

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

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

Given the tool's complexity (destructive, ownership logic, multiple identifier types, a flag), the description covers the main usage requirements and constraints. It explains the default behavior, the flag's usage, and the same-browser limitation. It doesn't describe return values, but the presence of an output schema shifts that responsibility. It doesn't detail failure modes, but that is not essential 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 fully compensate. It explains tab_id as native tab id or composite session_id, and notes it can be a single identifier or list. It explains owner_id is required by default and comes from open_new_tab. It explains only_if_agent_owned flag's purpose and default. It also clarifies that identifiers must belong to the same browser. Every parameter is given meaning beyond its schema type.

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

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

The description explicitly states the verb and resource: 'Close one or more tabs'. It specifies the identifier types (native tab id or composite session_id) and that it can accept a single or list. This clearly distinguishes it from sibling tools like switch_tab or activate_tab, which perform different actions on tabs. The purpose is 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 usage context: it defaults to closing only agent-created tabs, requires owner_id from open_new_tab, and explicitly instructs when to set only_if_agent_owned=false (only for explicit operator request). It also notes that identifiers must belong to the same browser. It doesn't mention alternatives because no other close tool exists among siblings, but it clearly defines the intended use case and constraints.

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

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

The description adds behavioral context beyond annotations: it does not foreground the tab, is bounded, and is session-specific. It also discloses the concurrency behavior (capture_busy). Annotations already declare destructiveHint=true, and the description does not contradict this; it supplements with operational details. However, it doesn't explicitly explain what side effects or resource consumption occur, but the added traits are valuable.

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 concise sentences, front-loaded with the primary purpose, followed by usage instructions and a concurrency note. Every sentence adds essential information with no redundancy. It is efficiently structured and easy to scan.

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 purpose, lifecycle, and concurrency, but it omits parameter semantics entirely. While an output schema exists (not shown), the parameters are undocumented in both schema and description, which is a significant gap for a tool with 3 optional parameters. It also doesn't mention prerequisites like having a tab open, though that's implied by 'real-browser tab'. Overall, it's adequate but not fully complete.

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

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

The input schema has 3 parameters with no descriptions (schema coverage 0%), and the description fails to explain what timeout, session_id, or max_entries mean. The term 'bounded' hints at limits but doesn't tie it to the parameters. With zero schema descriptions, the description must compensate, but it does not, leaving the agent to guess parameter meanings.

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 ('Start'), the resource ('Runtime console and exception capture'), and the scope ('on a real-browser tab without foregrounding it'). It also introduces the 'bounded' qualifier, which distinguishes it from unbounded captures. The purpose is unambiguous and distinct from sibling tools like network_capture_start.

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 lifecycle guidance: use get_console_messages while running and console_capture_stop when done, all within the same MCP session. It also warns about the capture_busy condition when another session is capturing and advises using a separate tab per agent. This clearly delineates when to use this tool and how to handle conflicts.

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

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

The description discloses the session ownership constraint and the error condition (capture_busy), adding value beyond annotations. It also mentions returning the buffer and releasing the lease, which are behavioral details. However, it doesn't state whether the buffer is cleared after retrieval or other side effects, but annotations already mark it destructive, so the description is sufficiently transparent.

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

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

Two concise sentences with no redundant words. The core purpose is front-loaded, and the ownership condition is stated immediately after. Every sentence adds necessary context.

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

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

The description covers the main action and an important precondition, and an output schema exists to describe the return value. However, it omits any explanation of the two parameters, and it doesn't explicitly state that capture must already be active (though implied by 'stop'). The missing parameter semantics is a notable gap for a tool with 0% schema coverage.

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 provides no explanation of the timeout or session_id parameters. The mention of session ownership hints that session_id might identify the starting session, but it's not explicit. With zero parameter documentation in the schema, the description fails to compensate, leaving the agent to guess the meaning and usage of both 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 clearly states the action: 'Stop console capture on a real-browser tab, return the remaining bounded message buffer, and release its debugger lease.' It names the specific resource (console capture) and the operation, distinguishing it from console_capture_start and get_console_messages by virtue of being the stop 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 provides a clear ownership precondition: 'Only the MCP session that started the capture may stop it; another session gets capture_busy.' This explicitly tells the agent when the tool can be used and what happens otherwise. It doesn't explicitly say 'use when you want to end capture,' but that is implied by the action verb.

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

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

Annotations already indicate this is a mutating, non-idempotent operation, and the description adds meaningful behavioral detail beyond that: url presence switches the resource type between bookmark and folder, and parent_id falls back to Chrome's default location. This gives the agent useful operational expectations without contradicting the annotations.

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

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

Two short, front-loaded sentences cover the core behavior, the main conditional, and the default behavior. Every sentence earns its place and there is no filler or repetition of schema 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 is sufficient for the basic call paths: create a bookmark, create a folder, or choose a parent folder. The output schema covers return values, and annotations cover mutation and idempotency expectations. The only notable omission is session_id, whose purpose is not explained, so the description is not fully complete for all optional parameters.

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 carry the parameter semantics. It explains url and parent_id well, including their conditional and default behavior, and title's required role is inferable from the schema. However, session_id is completely undocumented in both the schema and description, leaving a meaningful gap for a 4-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 clear action and resource ('Create a bookmark or folder') and immediately clarifies the core distinction: supply a URL for a bookmark, omit it for a folder. This is specific enough to clearly distinguish it from sibling tools like get_bookmarks and remove_bookmark.

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

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

The description gives explicit conditional guidance for the main decision the agent must make: whether to include url or omit it to create a folder. It also explains parent_id's default behavior. It does not name alternative tools or explicitly say when not to use this tool, but the create-versus-read/delete contrast with siblings is clear.

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

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

Annotations already declare the tool read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context about the scope of targets returned and the fact that it works without open tabs, which goes beyond the annotations and helps the agent predict 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 tight sentences with no filler. The core action and scope are front-loaded, and the contrast with list_tabs earns its place by adding useful differentiation.

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 list tool, the description covers the main use case, scope, and an important edge case (no tabs open), while an output schema exists so return values do not need explanation. The only clear gap is the undocumented optional session_id parameter.

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

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

Schema description coverage is 0%, and the description does not mention the optional session_id parameter at all. Since the description bears the burden of explaining parameters when the schema does not, this is a significant 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 ('List') and a precise resource ('every CDP-attachable target'), and differentiates itself from list_tabs by explicitly naming service workers and extension background pages. This makes the tool's purpose unmistakable and distinguishes it from siblings without opening schemas.

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

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

The description gives clear context: it is the tool to use when you need CDP targets beyond what list_tabs shows, and it works even with no tabs open. It does not explicitly discuss when not to use it or compare it to other siblings like list_all_tabs, but the intended usage is evident.

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

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

Annotations already indicate destructive behavior (destructiveHint: true), but the description adds valuable detail about the mechanism: 'Uses CDP Network.deleteCookies, falling back to expiring it via document.cookie.' It also clarifies it operates on the 'real browser profile,' implying a persistent effect. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the primary action and scope, then adds the technical fallback. No fluff, every sentence earns its place. It is highly efficient and well-structured.

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

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

For a tool with 7 parameters and an output schema, the description covers the essential behavior: what it deletes, how it targets scope, and the underlying mechanism. It omits details on timeout, tab_id, and session_id, but those are likely generic across similar tools. Given the presence of an output schema, the return value is not explained but not critical. Overall, it is sufficiently complete for an agent to use correctly in most cases.

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 the core parameter 'name' and the scope parameters (url, domain, path) in context. However, it does not mention timeout, tab_id, or session_id, which remain undocumented in both schema and description. Partial coverage but not complete.

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 ('Delete a cookie by name') and the resource ('from the real browser profile'), which is specific and actionable. It also mentions scope options (current page or domain/path/url), adding clarity without confusion. It does not explicitly differentiate from sibling tools like set_cookies or get_cookies, but the action itself is 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 explains when to use it and how to adjust scope: 'Scope defaults to the current page (url), or pass domain/path/url to target another scope.' This gives clear conditions for parameter selection. It does not mention alternatives or when not to use it, but the scoping guidance is sufficient for most use cases.

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

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

The description discloses several non-obvious behaviors beyond the annotations: it waits by default, moves completed files into directory, avoids replacing existing files unless overwrite=true, falls back to Chrome's default download directory on timeout with directory_applied=false, and requires a live session_id. These are genuine behavioral disclosures, not just restatements of schema defaults.

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 not bloated, with the core purpose and usage guidance front-loaded. The sentence about the directory timeout reporting directory_applied=false is slightly awkward, but every sentence contributes useful information.

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

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

Given seven parameters and an output schema, the description covers the essential behavioral paths: download behavior, session/auth context, default waiting, directory fallback, overwrite policy, and recommended usage. The main gap is the absence of filename semantics and the exact behavior when wait=false, though the output schema can partially cover return structure.

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

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

Schema description coverage is 0%, so the description carries the full burden. It adds meaning for url, wait, timeout, directory, overwrite, and session_id, but it never explains the filename parameter or what happens when wait=false, so it doesn't fully compensate for the missing schema descriptions.

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

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

The description names the concrete action ('Download an http(s) URL through the real browser's native download manager'), the input, and the output (final absolute local path). It also distinguishes the tool from the page-fetch alternative, so an agent can tell exactly what this tool is for without inspecting 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?

It explicitly states when to prefer this tool: 'Use this for attachments instead of page fetch.' It additionally explains that the native download path uses the browser profile's cookies and authenticated session, which is the key context an agent needs to choose it over a raw fetch.

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

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

Despite the annotations already declaring readOnlyHint=false and destructiveHint=true, the description adds a wealth of beyond-annotation disclosure: side effects, replay prevention, timeout semantics, result invalidation, retry conditions, and conversion/result-delivery behavior. It fully warns the agent about consequences such as non-cancellation of page JS on timeout and the outcome_unknown window.

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

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

The description is a single dense paragraph that packs many distinct concerns into a long run-on structure. It is genuinely rich and mostly every sentence earns its place, but the overwhelming length and lack of section breaks make it harder to scan and reduce cognitive load for an agent. Some details about result_file encoding and retries could be reorganized into bullet-like clauses.

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

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

This is an extremely complex tool with six parameters, no schema descriptions, annotations that are broad, and an output schema that is declared but not available here. The description covers purpose, side effects, async behavior, result retrieval, timeout semantics, dialog policies, persistence of result output, fallback paths, and retry warnings. It is almost complete, yet it leaves 'no_monitor' undocumented and could benefit from explicitly naming each input parameter.

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

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

The schema descriptions are at 0% coverage, so the description must compensate. It adds semantic value to session_id, wait, timeout, dialog_policy, and the script body—e.g. wait=false returning an operation_id and the type of conversion behavior. However, it never mentions the parameter 'no_monitor' at all, and the timeout is only approached indirectly via 'deadline', leaving some meaning implicit.

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 sentence—'Execute arbitrary JS, which can cause side effects, in session_id's browser tab under one total deadline'—names a specific verb, resource, and key constraint. It clearly distinguishes this tool from siblings like get_execute_js_result and cdp_command: this tool executes JavaScript in the browser context, not just commands or result retrieval.

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

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

It provides explicit guidance on when to use wait_for/wait_for_url instead of sleep Promises, and explains how to collect the result with get_execute_js_result when wait=false. It does not explicitly state when not to use execute_js as opposed to specific alternative tools like cdp_command, but the purpose and fallback rules are clear enough for most use cases.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds resource specificity but does not disclose additional behavioral details such as error conditions or whether the path is guaranteed to exist. There is no contradiction with annotations.

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

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

A single, well-structured sentence with no filler. The key verb, resource, and purpose are immediately visible and front-loaded.

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

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

For a simple, zero-parameter, read-only getter with an output schema and safety annotations, the description is complete. It states what the tool returns and why it is used. Nothing essential is missing.

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

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

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to add about arguments. The baseline of 4 applies because no parameter documentation burden exists.

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') and resource ('absolute path to the unpacked Chrome extension directory'), and it states the purpose ('for manual installation'). This clearly distinguishes it from sibling tools like list_extensions, set_extension_enabled, and uninstall_extension, which perform different operations.

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

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

The phrase 'for manual installation' provides clear context for when this tool is appropriate. It does not name alternatives or exclusions, but the zero-parameter read-only nature and highly specific resource make ambiguity unlikely.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, so the description correctly does not restate these. It adds valuable context by explaining that lab is the default and skips elicitation unless BROWSERTAP_LAB_NO_ELICIT is disabled, and that safe requires approval for every physical action. This goes beyond the annotation metadata.

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, efficient sentence that front-loads the core purpose and then provides essential behavioral details. No filler or repetition—every clause earns its place.

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

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

For a parameterless getter with an output schema present, the description covers all necessary information: what it returns and the meaning of the two profile modes. The agent has enough to call it correctly without additional documentation.

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 schema coverage is trivially 100%. Per the rubric, a 0-parameter tool receives a baseline of 4. The description adds no parameter information because none exists.

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

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

The description clearly states the tool's purpose: 'Return the active safe/lab automation profile.' It names the specific resource (automation profile) and distinguishes between two profile types, which is unambiguous and differentiates it from set_automation_profile and other sibling tools.

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

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

The description explains the behavioral differences between lab and safe profiles, which is useful context, but it does not explicitly state when to use this tool versus alternatives like set_automation_profile. Usage is implied by the name and purpose, but no direct when-to-use or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds one behavioral fact beyond annotations ('Works with no tabs open'), but it does not explain session_id behavior or other runtime behavior, so the added transparency is minimal.

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, front-loaded with the core action and immediately followed by a relevant availability condition. There is no filler and every word earns its place.

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

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

For a tool with no required parameters, rich read-only annotations, and an output schema, the description gives enough context to call it correctly, including the no-tabs-needed condition. The only completeness gap is the undocumented session_id semantics, which is mitigated by it being optional with a null default.

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

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

The only parameter, session_id, has no schema description (schema_description_coverage is 0%) and the description never mentions it. Because coverage is low, the description needed to compensate, and it does not. The parameter is optional with a default null, so the harm is limited, but semantics are entirely unexplained.

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 ('Return the browser bookmark tree') and adds a scoping condition ('Works with no tabs open'). It is immediately distinguishable from siblings like create_bookmark and remove_bookmark because it clearly identifies the read operation and the bookmark resource, not tabs.

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 'Works with no tabs open' communicates a concrete context in which this tool can be used, distinguishing it from tab-oriented siblings (list_tabs, switch_tab, etc.). It does not name explicit alternatives or exclusions, but the use case is clear for a simple read-only bookmark query.

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

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

Annotations already mark this as potentially destructive, and the description adds crucial nuance: only clear=true clears the buffer, only the originating session may do so, other sessions get capture_busy, and non-clearing reads are shared. It also explains the exact effect of filter='user'. This is strong behavioral disclosure beyond the annotations.

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

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

Three focused sentences: the first states the core purpose, and the next two add essential behavioral and filtering details. There is no filler, redundancy, or wasted structure, and the most important information is front-loaded.

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

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

The description covers the core operation, destructive-session semantics, sharing behavior, and filtering. An output schema exists, so return-shape documentation is unnecessary. However, because six parameters exist with zero schema coverage, leaving offset/timeout/max_items/session_id unexplained prevents the description from being fully complete.

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

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

With 0% schema description coverage, the description must compensate, but it only explains clear and filter. offset, timeout, max_items, and session_id are left entirely to inference from their names and defaults, and session_id in particular is ambiguous without explanation.

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 ('Read'), a specific resource ('captured console messages and exceptions from a real-browser tab'), and clarifies the pagination concept ('a page'). This makes its role clear and distinguishes it from console-capture start/stop siblings and from execute_js.

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 text strongly implies this tool is used after a console capture has been created by mentioning 'capture's originating MCP session', but it never explicitly says 'use after console_capture_start' or identifies situations where an alternative should be chosen. Parameter-level guidance is provided, but tool-selection guidance is only 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful scope context ('current page or specified tab') and the extension-bridge mechanism, but it does not disclose what cookie set is returned, whether domain filtering applies, or how session_id affects 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?

It is a single, front-loaded sentence with no wasted words. The main cost is under-specification, which is already penalized in other dimensions rather than in structure.

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 two optional parameters and an output schema, but session_id remains entirely opaque and no guidance is given about precedence if both tab_id and session_id are supplied. Because one of the two parameters is unexplained and no usage context is provided, the definition is not complete enough for reliable 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?

With 0% schema description coverage, the prose needed to explain both parameters. 'Specified tab' partially conveys tab_id, and 'current page' hints at the null-tab default, but session_id is never mentioned or explained. The description compensates for one parameter, not the other.

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

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

The description names the resource ('cookies'), the scope ('current page or specified tab'), and the mechanism ('Chrome extension bridge'), so an agent can tell it is a read operation distinct from set_cookies/delete_cookies. It does not explicitly reference a sibling tool or formalize what 'current page' means, so it stops short of perfect differentiation.

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

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

No guidance is given about when to use this tool versus its siblings set_cookies, delete_cookies, or other cookie-related tools. The description implies it should be used when cookie values are needed, but it never states alternatives, exclusions, or prerequisite 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 readOnlyHint=false, openWorldHint=true, and no idempotency guarantee, the description must carry the behavioral burden, and it delivers extensively: timeout bounds (0-120 seconds), retention limits (10 minutes, 512 records, capacity eviction), unknown/expired semantics, late_result with late_reply_age, reservation/release behavior, and encoding rules. None of this contradicts the annotations; the reservation language actually explains why the tool is not purely read-only.

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

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

The text is a single unbroken ~200-word wall of dense, multi-clause sentences filled with jargon ('reservation_held describes that probe, not a prior mutation'). It is properly front-loaded — the purpose leads — and every sentence carries real facts, but the lack of any structural breaks makes the critical guidance costly for an agent to parse.

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

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

Given the tool's high complexity (async reservations, retries, late results, unpaired-UTF-16 handling, export failure) and the presence of an output schema, the description covers nearly everything an agent needs: when to call, timeout range, retention, retry semantics, late-result structure, and decode instructions. What keeps it from a 5 is pure structure, not missing information.

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

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

Schema description coverage is 0%, so the description must compensate. It adds a concrete meaning to timeout ('timeout is 0-120 seconds') and clarifies that operation_id originates from execute_js or bridge commands, including the nested-vs-outer distinction. It doesn't state the operation_id format, but for a zero-coverage schema this is solid 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 opening phrase names a specific verb-resource pair — 'Read or wait for an operation_id' — and scopes it to execute_js or other timed-out bridge commands, which separates it from the sibling list at a glance. It even carves out the nested open_new_tab reconciliation case, so an agent knows exactly what this tool is for.

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 explicit routing guidance: 'Call from the submitting MCP session' plus the exclusion 'The outer tab-creation ID uses open_new_tab recovery,' which tells the agent when not to use this tool and names the alternative. It doesn't enumerate all other alternatives, but it does resolve the two most likely confusion points (execute_js results and open_new_tab nested vs. outer IDs).

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

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

Discloses significant non-obvious behavior beyond annotations: possible Windows ACL tightening, token file creation during bridge startup/auth initialization, answering while another tool is still running, session isolation, and malformed remote diagnosis handling. These complement and align with the annotations rather than contradicting them.

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

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

The description is front-loaded with the core purpose and each sentence adds diagnostic nuance, but it is extremely dense and runs as one long paragraph. It could be tightened with bullet-style grouping, though it stays on-topic and avoids filler.

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

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

Given the output schema already exists and there are no input parameters, the description is remarkably complete: it covers every verdict family, special false/unknown values, side effects, concurrency behavior, and even Windows-specific behavior. An agent has enough context to invoke and interpret this tool correctly.

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

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

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to document. Schema description coverage is 100% and the no-parameter baseline of 4 applies; the description correctly spends no effort on 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: 'Return component versions, stale-build actions, extension path, bridge ports, and connection status for setup/diagnostics.' It enumerates concrete output categories and clearly frames the tool as a setup/diagnostics status tool, distinguishing it from sibling tools like extension_path or get_automation_profile.

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

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

The description gives clear context for when to rely on its results and maps diagnostic verdicts to follow-up actions: 'wait_for_extension', 'check_extension_connection', 'restart_mcp_session', and 'restart_bridge'. It does not explicitly name sibling alternatives or when-not conditions, but the action mappings effectively convey usage 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?

The description adds value by explaining that 'manual' reports the dialog without choosing, which clarifies one non-destructive behavior. However, it does not elaborate on the effects of dismiss or accept (e.g., losing unsaved changes, clicking OK/Cancel), and it does not explain the role of timeout or session_id. Since the annotations already declare destructiveHint=true, the description doesn't contradict them but doesn't add much beyond that.

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

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

The description is extremely concise: two sentences that state the purpose and list the action options. There is no wasted text, and the core information is front-loaded. This is an efficient use of words.

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

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

The tool has four parameters, one required, and an output schema, but the description does not cover essential context. It omits the meaning of timeout (likely how long to wait for the dialog), session_id (which tab), and prompt_text (input for prompt dialogs). It also doesn't explain what happens after the action (e.g., return value or page behavior). For a tool that can destructively handle dialogs, this is under-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?

With 0% schema description coverage, the description must explain the parameters. It only explains 'action' by listing valid values (dismiss, accept, manual). The other three parameters (timeout, session_id, prompt_text) are not described at all, leaving the agent without necessary information to use them correctly. The description partially compensates for the lack of schema documentation but is insufficient.

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

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

The description clearly identifies the tool's function: inspecting or handling a JavaScript dialog on a real-browser tab. It specifies the resource (JavaScript dialog) and the action (handle/inspect), and lists the valid action values. However, it does not explicitly differentiate from the sibling tool resolve_leave_dialog, which might also handle a specific type of dialog.

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 no guidance on when to use this tool versus alternatives such as resolve_leave_dialog or other dialog-related tools. It does not state when to use dismiss versus accept versus manual, nor does it mention prerequisites like whether a dialog must already be present. The usage context is implied but not explicit.

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

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

The description goes well beyond the sparse annotations by disclosing the 'temporary per-ticket window identity marker' side effect, clarifying that it 'does not activate a window,' and describing refusal behavior. It also explains the verification steps and the 15-second ticket produced for cancel_native_file_dialog. This adds meaningful behavioral context the annotations do not provide.

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 adds value: scope, prerequisites, verification behavior, side effect, returned ticket, and routing advice. It is front-loaded with the core capability and avoids 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?

Given the tool's moderate complexity, the description covers prerequisites, exact behavior, side effects, non-activation, refusal cases, and the link to cancel_native_file_dialog. The presence of an output schema means return-value details need not be fully spelled out in the description, and the remaining guidance is complete enough 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?

With 0% schema description coverage, the description carries the full burden and fully compensates by explicitly saying it 'Requires desktop_opt_in=true.' It also ties the boolean parameter to a concrete precondition, which is more useful than the schema's bare default.

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: 'inspect the current foreground Windows native file dialog owned by a registered Chrome or Edge process.' It also distinguishes itself from ordinary-page tools by noting 'Use page/CDP tools for ordinary pages' and refers to its companion sibling cancel_native_file_dialog.

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 states the required precondition 'desktop_opt_in=true and the desktop extra' and gives a clear routing rule: 'Use page/CDP tools for ordinary pages.' It also notes that unsupported or unverifiable native layouts are refused, which helps an agent decide when not to attempt the tool.

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

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context: chrome-extension pages cannot become sessions, have no session id, and require cdp_command. It also notes the tool works with no tabs open, covering an edge case beyond annotations.

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

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

Three sentences, each carrying distinct information: the listing scope, the chrome-extension caveat, and the empty state. The key differentiator is front-loaded and there is no filler.

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

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

Given the read-only nature, strong annotations, and an output schema, the description covers the key behavioral distinctions and edge case. The only minor gap is the unexplained session_id parameter, but it is optional and not central to using the tool correctly.

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

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

Schema coverage is 0% and the description doesn't explain the optional session_id parameter. However, the parameter is optional and defaulted to null, making it less critical. Still, the description adds no semantic meaning for the parameter, so baseline 3 applies.

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

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

The description clearly states a specific verb and resource: 'List every open tab', and immediately differentiates from sibling list_tabs by noting it includes chrome-extension:// pages that list_tabs hides. This lets an agent distinguish the tools without inspecting 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?

Explicitly names list_tabs as the alternative and explains the distinguishing condition: chrome-extension pages. It also provides actionable routing guidance by telling the agent to drive those tabs with cdp_command(tab_id=...) since they have no session id.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by noting the tool works with no tabs open and by specifying the output fields, which is genuinely useful behavioral context beyond the annotations.

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

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

The description is a single efficient sentence plus a compact field list. Every element earns its place, with the most important verb and resource front-loaded.

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

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

This is a low-complexity read-only listing tool with an output schema and strong annotations. The description communicates the purpose, the returned fields, the 'no tabs needed' precondition, and the safety profile is already covered by annotations, so nothing essential is missing.

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

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

Schema description coverage is 0%, and the description does not mention session_id at all. The only parameter is an optional nullable string with a null default, so the schema carries almost no semantic information. The description's listing of output fields does not compensate for the absence of parameter 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 states a clear verb and resource: listing installed browser extensions, and even enumerates the returned fields (id, name, enabled, type, version). This distinguishes it from sibling tools like call_extension, set_extension_enabled, or extension_path, which operate on extensions rather than listing 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 phrase 'Works with no tabs open' provides a useful context that this operation does not require an active tab, which helps differentiate it from tab-dependent tools. However, it does not explicitly state when to prefer this over siblings or mention any 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?

The description goes well beyond the readOnly/idempotent annotations by disclosing concurrency behavior, snapshot isolation of the default session, and the bridge-reservation semantics on timeout versus pending mutations. This is exactly the kind of non-obvious behavior an agent needs to invoke the tool safely.

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

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

The description is front-loaded with the primary purpose and then compacts several distinct behavioral facts into tight sentences with no filler. Each sentence adds new information about scope, concurrency, session handling, or reservation semantics.

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

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

The description is thorough for a tool with no input parameters and an output schema, covering concurrency and session isolation. The main gap is that it never clarifies how list_tabs differs from the sibling list_all_tabs, and the session_id instructions assume context the schema does not expose.

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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds relevant session_id context even though it is not a schema property, which is helpful for understanding the tool's operating model, though it slightly muddles the fact that no input parameters are accepted.

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 connected tabs across all connected browsers' and states the key output fields (browser, session id). It is clear at a glance, but it does not explicitly differentiate itself from the closely named sibling list_all_tabs, so the agent must infer the distinction.

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 operational context: it can answer while another tool is running, and it instructs agents to pass session_id explicitly when sharing one MCP process. It does not, however, state when to prefer this tool over list_all_tabs or other sibling 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?

Beyond the annotations, the description discloses several important behaviors: the capture is bounded, it does not foreground the tab, it acquires a debugger lease that must be released via network_capture_stop, and another session's capture will return capture_busy. This is exactly the practical behavioral context an agent needs.

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

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

The description is three tight sentences with no filler. It front-loads the action and output, then immediately provides the critical stop-and-concurrency instructions. 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?

An output schema existsbool and all parameters are optional with defaults, so the default invocation path is well covered. The main gap is parameter-level detail for custom capture limits and session_id, but the description supplies the most important lifecycle and concurrency context.

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

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

Schema description coverage is 0%, and the description only vaguely addresses parameters: 'optionally response bodies' hints at include_bodies alert and 'bounded' hints at limits. It does not explain timeout, session_id, max_entries, body_timeout, or max_body_bytes, so the agent must rely on parameter 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 description clearly identifies the verb ('Start'), the resource ('CDP Network capture'), and the target context ('real-browser tab'). It also states exactly what is captured ('requests, responses, and optionally response bodies'), making it easy to distinguish from network_capture_stop and console_capture_start.

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 lifecycle guidance: call network_capture_stop from the same session to retrieve the buffer and release the debugger lease. It also warns about concurrent sessions returning capture_busy and directs the agent to use a separate tab per agent. It does not contrast this with related tools like console_capture_start, but the operational context 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?

The description adds behavior beyond the annotations by disclosing the release of the debugger lease, the structured error for invalid RegExp, and the capture_busy outcome for unauthorized sessions. These are specific behavioral traits not present in readOnlyHint, openWorldHint, or destructiveHint, and they do not contradict the annotations.

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

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

Three sentences, each carrying essential information: the core action and filter options, the RegExp syntax and error behavior, and the session ownership constraint. It is front-loaded with the primary purpose and contains 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?

With an output schema present, the description does not need to cover return values. It covers ownership, error cases, and the filtering dimensions, but it leaves timeout and session_id unexplained. Given the 7-parameter schema with zero descriptions, this is a small but notable gap, so the description is not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain that optional filtering can be done by URL, resource type, HTTP status range, and response-body inclusion, and it defines the url_pattern syntax and error behavior. However, it does not explain timeout or session_id, and it does not map the filter categories to the exact parameter names, leaving some parameter meaning unresolved.

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

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

Description states a specific verb and resource ('Stop Network capture') and adds that it releases the debugger lease. It is clearly distinguished from the sibling network_capture_start and console_capture_stop by name and action, so an agent can identify what this tool does.

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

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

It gives clear context for use by describing that only the session that started the capture may stop it and that another session gets capture_busy. It does not explicitly mention when to prefer this over alternatives like console_capture_stop, but the 'stop network capture' action and ownership rule make usage conditions clear. No explicit exclusions of siblings, so not 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?

While annotations already mark this as non-read-only, non-idempotent, open-world, and destructive, the description goes far beyond them with detailed side-effect and recovery behavior: probe uncertainty, retry_safe semantics, ownership requirements, worker-restart terminal states, and reconciliation resumption. No contradiction with annotations is present.

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

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

The first sentence is well front-loaded, but the remainder is a dense, semicolon-heavy paragraph mixing several distinct recovery concepts. Every sentence adds information, but poor structural grouping makes it harder for an agent to parse under pressure.

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 this much recovery and deduplication complexity, the description is remarkably complete: it covers probe uncertainty, retry rules, ownership, failed recovery, worker restart, reconciliation guidance, and invalid evidence. Since an output schema exists, omitting return-value details is acceptable.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does explain operation_id, active, owner_id, client_id, and session_id in context. However, timeout is not addressed, and URL only receives implicit treatment, leaving a small semantic gap for a tool with seven parameters.

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

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

Description opens with a specific verb and resource: 'Create one background browser tab, deduplicated by operation_id.' This immediately distinguishes it from related tools like list_tabs or switch_tab, and the deduplication qualifier adds a precise scope.

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

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

The description gives concrete usage instructions: use the MCP task's selected browser, select another via switch_tab or session_id/client_id when needed, pass active=true for foreground work, and save owner_id for cleanup. However, it does not explicitly contrast with alternatives such as open_url or say when not to use this tool.

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

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

The description adds meaningful behavior beyond the annotations: it navigates without raising the window, handles beforeunload with a default of dismiss, auto-accepts in lab mode for configured hosts, and explains how to override with 'accept', 'manual', or 'intent_leave=false'. This is substantial, non-contradictory context that an agent needs to predict side effects and page-unload behavior.

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

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

Two focused sentences place the core purpose first and then dive into the most nuanced behavioral mode. The beforeunload clause is dense but earns its place by clarifying a confusing default. Slight loss of a point because the phrasing is telegraphic and an agent might need to re-read the lab-auto-host clause.

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 beforeunload modes are well covered, and the presence of an output schema means return value detail is unnecessary. But with 5 parameters, 0% schema coverage, and no mention of timeout or session_id, the definition is not fully complete. The description gives enough for successful navigation but leaves parameter semantics partially depend, on the schema 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?

The schema has no property descriptions (0% coverage), so the description carries the burden for parameter meaning. It clearly explains beforeunload and intent_leave semantics, and url/tab are evident from the purpose. However, it leaves timeout and session_id completely unexplained, so the agent still lacks the full parameter semantics for a 5-parameter schema.

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

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

The description opens with a specific verb and resource: 'Navigate the current real-browser tab through CDP without raising its window.' This clearly distinguishes the tool from siblings like open_new_tab (new tab), cdp_command (raw CDP), and activate_tab (focus/window behavior). The 'current real-browser tab' wording makes the scope unambiguous and the mechanism CDP-specific.

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

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

The description implies usage for the current tab versus opening a new one, but it never explicitly says 'use open_new_tab for new tabs' or provides exclusions. It does give rich guidance for the beforeunload parameter (accept, manual, intent_leave=false), which is useful, but lacks explicit when-to-use vs. sibling tools. The phrase 'without raising its window' hints at current-tab navigation but does not name an alternative.

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

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

Even with destructiveHint=true in annotations, the description adds substantial behavioral detail well beyond annotations: background CDP dispatch, no tab activation, no desktop cursor movement, none dispatched for ambiguous/unreachable targets, hit-testing, scrolling, obscured/outside_viewport, unsupported_frame_transform, stale_frame, and input_dispatched guidance. This is far beyond the annotation metadata.

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 long but dense and logically organized, front-loading the core purpose and critical coordinate caveat before mode-specific details. Every sentence adds distinct information, though headings or bullet structure could improve scannability. It is appropriately detailed for the tool's complexity, not padded.

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 9-parameter tool with a long tail of edge cases, the description is remarkably complete: it covers coordinate conversion, selectors, offsets, frame and OOPIF behavior, hit-testing, statuses, scrolling, and stale-frame recovery with a warning to inspect input_dispatched. Since an output schema exists, return-value details are not required from the description.

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 carries most of the semantic burden, and it delivers for key parameters: x/y as viewport CSS pixels requiring devicePixelRatio conversion, selector object forms as CSS aliases or frame-point mode, and offset_x/y measured from top-left with omitted axis centered. It does not explain button, clicks, timeout, or session_id, so it is not fully complete for every parameter.

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

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

The opening sentence states a specific verb and resource: "Click a CSS/structured locator or viewport coordinates in a specific real browser tab using background CDP input." It clearly identifies two input modes, distinguishes itself from screenshot coordinate semantics by referencing capture_page_screenshot, and separates click behavior from type/press siblings.

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

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

The description provides clear context for when to use coordinate mode versus selector mode, including explicit differences like "Coordinate mode is not hit-tested -- coordinates name a pixel, not an element." It also references fallback "query/type paths" in the transformed-iframe case, though it does not systematically enumerate sibling alternatives for all scenarios.

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

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

The description adds meaningful behavioral detail beyond the annotations: it uses one CDP input sequence, runs in the background, never activates the tab, never moves the desktop cursor, and performs no hit-testing on either endpoint. These are exactly the side-effect traits an agent needs to know. The description is consistent with the annotations, including the destructiveHint and readOnlyHint flags.

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

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

The description is two concise sentences with no filler. The primary action and tab context are front-loaded, and the coordinate semantics and behavioral caveats come immediately after. Every clause adds information an agent can act on.

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 drag tool with a relatively small parameter set, the description covers the core behavior, coordinate semantics, background execution, and hit-testing behavior. An output schema exists, so a return-value explanation is unnecessary. The main gap is that optional parameters like duration and button receive no context, though their defaults and intuitive names reduce the risk.

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 itself has 0% parameter description coverage, so the description must compensate. It does clarify the four required coordinate parameters by stating that both endpoints are viewport-relative CSS pixels and are not hit-tested. However, it says nothing about the optional button, duration, timeout, or session_id parameters, leaving those to be inferred from defaults or names.

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 a specific action: drag between viewport coordinates in a specific tab. It also distinguishes itself from related tools by noting it runs as a background CDP input sequence, does not activate the tab, and does not move the desktop cursor. This gives an agent enough to separate page_drag from page_click, page_type, and similar input tools.

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

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

The description gives clear behavioral context that implies when to use this tool: use it for viewport-relative drags that should happen in the background without tab activation or desktop-cursor movement. It even references page_click's coordinate mode as a point of comparison. It does not explicitly state when not to use it or name an alternative beyond the implicit page_click analogy, so it stops just short of full 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?

The description adds useful behavioral context beyond the annotations, especially the key fact that input is delivered via background CDP and does not activate the tab. The annotations already indicate destructive potential and non-read-only status, and the description does not contradict them.

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, tightly packed sentence that front-loads the action and includes only essential qualifiers. No filler or redundant 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?

The description covers the core invocation details for a simple tool, and the presence of an output schema plus annotations fills in return and safety information. Minor ambiguity remains around the exact key-chord syntax and the optional session_id behavior, but the description is largely complete for correct use.

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

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

With 0% schema description coverage, the description adds meaning to keys_csv by explaining that it accepts a key or comma-delimited modifier chord. It is less explicit about timeout and session_id, but those parameter names are reasonably self-explanatory and the description's clarification is valuable beyond the bare schema.

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

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

The description clearly states the action ('Press a key or comma-delimited modifier chord'), the target ('in a specific tab'), the mechanism ('background CDP input'), and a distinguishing behavior ('without activating the tab'). This makes it easy to tell apart from siblings like page_click and page_type.

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

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

The description clearly communicates when to use this tool: for keyboard input in a background tab without activating it. It does not explicitly mention alternatives or say when not to use it, but the context is clear enough for an agent to select it over page_type or page_click.

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

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

Annotations declare destructiveHint=true, and the description expands on this with concrete behaviors: optional clear/submit, retargeting for xterm, reduction to visible interactable candidates, trusted input events, focus_confirmed output, stale_frame on navigation, and replay warnings. No contradiction with annotations.

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

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

The description is verbose, with several long sentences packed with edge cases and implementation details. It is front-loaded with the core action, but the subsequent sentences could be trimmed or grouped. Overly detailed for a quick scan.

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?

Behaviorally it covers many scenarios (missing targets, stale frames, retargeting, auditable output), and an output schema exists so return values are handled. However, it fails to explain the timeout and session_id parameters, which are part of the input schema, leaving agents to guess their semantics. This gap prevents full 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 description coverage is 0%, so the description must compensate. It indirectly covers text, clear, submit_key, and selector behavior, but timeout and session_id are not explained at all. Even for the covered parameters, details like accepted formats or defaults are omitted.

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 ('Insert text') with a clear resource ('focused element or CSS/structured-locator field') and distinguishes it from siblings like page_click and page_press. The purpose is unambiguous and the technical mechanism (background CDP input) adds specificity.

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

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

Provides context about when it applies (focused element, selector, xterm retargeting) and conditions like missing/ambiguous targets dispatching nothing. However, it does not explicitly name alternatives or exclusion criteria, such as 'use page_press for key-only input' or 'use execute_js for complex scripting'.

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

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

Annotations already flag destructiveHint=true, but the description adds substantial behavioral detail: atomic JSON backup, failure semantics ('nothing is removed if the snapshot or backup fails'), backup directory constraints (not a symlink/reparse point), return behavior even when outcome unknown, retention policy (30 days / 100 files / 64 MiB), per-subtree limit, and non-transactional concurrency note. All this goes beyond the annotations and is highly valuable for an agent.

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

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

The description is front-loaded with the core action, then packs essential caveats into a compact paragraph. Every sentence adds information (backup, failure behavior, limits, concurrency). Slightly long but justified given the complexity. No fluff.

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

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

Given the tool's complexity (backup, recursive folders, failure handling, output), the description covers the key aspects: what happens on failure, return value expectations, backup lifecycle, and non-transactional nature. It does not explain session_id usage, and the output schema is present but not elaborated, yet the description mentions backup_path so the return contract is clear. Overall sufficient for an agent to call it safely.

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 recursive clearly ('full subtree should be removed'), and bookmark_id is self-explanatory from the name and usage. However, session_id is not mentioned at all – its semantics remain unexplained. This partial coverage nets a 3.

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

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

Description starts with 'Remove a bookmark by id' – a clear verb+object. It distinguishes itself from create_bookmark and get_bookmarks by explicitly naming the resource (bookmark) and the operation (remove). The recursive flag is explained as an option for folders, so the purpose is precise.

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 guidance on when to set recursive=true ('only for a folder whose full subtree should be removed'), which helps decide parameter usage. However, it does not contrast with siblings like get_bookmarks or create_bookmark – no explicit 'use this when' or 'instead of' statement. The reader must infer that removal is the intent.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false. The description adds valuable context: it attempts restoration, handles manual_recovery records, and on unsupported restoration it preserves prior settings and stops automatic retries. This goes beyond the annotations and explains side effects and failure behavior.

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

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

The description is compact and front-loaded with the main action ('Attempt to restore matching temporary site-permission leases now'). Each sentence adds distinct information: scope, parameter constraints, failure behavior, and guidance. Slightly dense but no wasted words.

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

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

Given the tool has an output schema and annotations, the description covers the key behavioral aspects: what it resets, how to scope it, and what happens on unsupported restoration. The only gap is session_id semantics, but overall the description is sufficient for an agent 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%, so the description must compensate. It explains the semantics of 'origin' and 'permission' (omitting both resets all leases; origin only http/https), but it doesn't explain 'session_id' at all. The description adds meaning for two of three parameters, but the third remains undocumented.

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 ('reset') and resource ('temporary site-permission leases'), and clarifies scope ('for the selected browser'). It distinguishes from siblings by mentioning 'manual_recovery records' and 'automatic retries', which are not present in sibling names like set_site_permission. However, it doesn't explicitly name a sibling alternative, so it's clear but not fully differentiated.

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 conditions: 'Omit origin and permission to reset every lease for the selected browser; origin accepts only http/https.' It also explains when not to use it: 'Unsupported restoration preserves the prior setting... stops automatic retries. Resolve that cause before another explicit reset.' This is clear context, though it doesn't name alternative tools explicitly.

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

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

Annotations already indicate destructiveHint=true, and the description adds substantial behavioral detail: the two-step accept protocol, the early return when no dialog exists, the lab-only fallback condition (only when protocol handling fails), and the exposed failure reasons (elicitation_unsupported, declined, timeout, cancelled, error). This goes well beyond the annotations and gives the agent a clear model of the tool's actions and outcomes.

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

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

The description is a single, information-dense sentence that front-loads the purpose and then details the workflow and failure modes. While complex, it avoids redundancy and every clause adds meaningful information. It is structured logically and not overly verbose.

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

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

Given the output schema exists (so return values are covered) and the annotations declare destructiveHint, the description provides sufficient context for an agent to understand when to call the tool and what it does. It covers the main workflow, edge cases (no dialog, fallback), and failure reasons. It does not mention prerequisites like page state or session validity, but these are likely not essential for a bounded workflow. The description is nearly complete for its complexity.

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

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

The schema has a single optional parameter, session_id, with default null, and the description does not mention it at all. Schema coverage is 0%, so the description does not compensate. However, since the parameter is optional and may be ignorable, the gap is less severe, but it is still a missing explanation for a parameter that could affect behavior.

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

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

The description clearly identifies the tool as resolving an intended beforeunload leave, with a specific workflow: accept protocol twice, return when no dialog exists, and use a fallback Enter key after approval gate fails. It names the exact failure modes and distinguishes itself from generic dialog handling by specifying the beforeunload context, making the purpose unambiguous even without referencing siblings.

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

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

The description implies the tool is for beforeunload dialogs and describes when it returns immediately (no dialog) but does not explicitly state when to use this tool versus alternatives like handle_dialog. It lacks an explicit exclusion or comparison, so an agent must infer the intended use from the beforeunload context. This is adequate but not explicit.

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

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

Adds substantial behavior beyond annotations: atomic write only after valid non-empty PDF bytes, CDP timeout invalidation, debugger lease detachment, and path validation. These details are not present in the annotations and meaningfully inform the agent of failure modes and write 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 sentences with purpose front-loaded and zero fluff. Every clause adds operational value (what it does, path restrictions, atomicity/timeout behavior).

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 8 parameters and the description leaves pivotal call semantics unexplained: how the tab is selected (session_id), the format of page_ranges, and the meaning of print options. The description covers path and timeout safety but is not complete enough for reliable invocation without external knowledge.

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