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

With no annotations, the description carries the full burden and does well: it discloses the side effect (token revoked on success), the blast radius (other managed sessions unaffected), and an error-semantics caveat about not_connected. It stops short of describing the success return value or whether the underlying Chrome process is terminated versus just deregistered.

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

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

Four short sentences, front-loaded with the action and scope before the caveats. Every sentence contributes, though the final broker/not_connected sentence is syntactically dense and could be split for clarity.

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

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

For a one-parameter, no-output-schema tool this covers intent, scope, side effects, and a failure-mode caveat. The only remaining gap is what a success response looks like, which is minor since no output schema is declared.

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

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

Schema coverage is 100% and the single parameter is already documented with an origin ('use the token returned by launch_chrome'). The description adds one useful semantic not in the schema: the token is revoked as a consequence of a successful close, reinforcing that this value is a capability that is consumed.

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

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

States a specific verb and resource: 'Explicitly close only the Chrome session identified by browser_token and revoke its token on success.' Scope is bounded ('only... Other managed sessions remain open'), which cleanly separates it from launch_chrome and the dialog 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?

Explicitly prescribes when to use (explicit close of one session) and when not to ('do not close it automatically at task completion'), and the phrase 'the reusable browser normally remains open across tasks' explains the rationale. It also warns that 'not_connected' from an absent broker is not evidence Chrome exited, preventing a common misdiagnosis.

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

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

With no annotations, the description carries the full load and does it well: it discloses that the token is one-use and that "Every read consumes the token, including failures", names the exact error payload (incorrect_dialog_count with expected_count and observed_count), and scopes the effect ("stops the operation attempt, not the conversation turn"). It also warns against capturing the browser through Computer Use while a dialog is pending.

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

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

The core action and its single-use constraint are front-loaded, and the behavioural rules follow in roughly priority order. It runs long for a two-parameter call, with some overlap between "After failure, stop dialog-handling attempts" and "Do not respond to another dialog, silently re-arm, or repeat the operation", but the redundancy reinforces a safety-critical constraint rather than padding.

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

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

No output schema exists, so the description supplies the return shape itself (Chrome-reported URL, type, message, one-use dialog_id) plus the failure payload. Combined with no annotations, the preconditions, consumption rule, and post-failure procedure make the definition self-sufficient for correct invocation.

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

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

At 50% schema description coverage, the schema documents browser_token (source and format) but says nothing about capture_id. The description supplies that capture_id names a capture interval that is consumed on read, which is real added meaning, but neither field's format or provenance is elaborated beyond the schema, so this sits at the baseline rather than above 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?

States a specific verb and resource ("End and consume the capture interval identified by capture_id") rather than restating the get_ name, and immediately signals the consuming semantics that separate it from get_dialog_status. The closing rules (do not respond, do not silently re-arm, do not poll) implicitly demarcate it from respond_to_dialog and start_dialog_capture.

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

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

Explicit preconditions ("Succeeds only if exactly one dialog-opening event was observed and that same dialog is still pending"), explicit prohibitions ("do not poll it", "Do not respond to another dialog, silently re-arm, or repeat the operation") and a prescribed failure path (stop attempts, inform the user with the observed count, ask the user to resolve). Little is left to inference.

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

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

readOnlyHint=true is consistent with a status query. Beyond the annotation, the description discloses the narrow return shape (booleans only, no dialog ID or provenance) and warns that a positive status must not be treated as authorisation to answer — a meaningful guard not present in structured fields. It does not explain failure behaviour when the browser is disconnected.

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

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

Three short clauses, front-loaded with the primary behaviour, then the return limitation, then the usage trigger. Dense but every clause carries distinct information; the middle clause about authorisation is slightly compressed in phrasing.

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

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

For a single-parameter read tool with no output schema and annotations covering the safety profile, the description covers purpose, return shape, and call timing. The only gap is what happens on an invalid or expired browser_token.

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?

One parameter at 100% schema description coverage, with the schema already explaining that browser_token is the private capability token from launch_chrome. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('Reports only whether the managed browser is connected and whether dialogs remain pending') and explicitly bounds the scope by saying no dialog ID or provenance is returned, which separates it from get_captured_dialog. An agent can distinguish this from all five siblings without opening a schema.

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

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

Gives two concrete invocation points ('before beginning a capture' and 'before resuming Computer Use after a successful response') plus an explicit exclusion ('does not authorise a response'). It stops short of naming the sibling that does return dialog details, so the routing is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: tokens grant access by possession, close_chrome revokes the token, adapter exit leaves the browser open, broker restarts require explicit reconnection, and captures do not survive restarts. It also discloses that failed launches may return a token for cleanup and that new versus reused instances behave differently regarding startup pages.

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 long, dense block that mixes launch semantics with dialog-capture workflow, Computer Use retry policy, and unrelated troubleshooting instructions. It is not front-loaded around launch_chrome's purpose and contains more operational detail than an agent needs to select and invoke this tool.

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

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

Given the tool's complexity and the absence of annotations or an output schema, the description is quite complete about session lifecycle, token handling, and failure modes. It is not perfect because the return shape is only loosely described through phrases like "returned browser_token" and "returned Windows identifiers," but it covers the critical operational 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?

The single parameter already has 100% schema coverage, but the description adds substantial meaning: keep the returned browser_token private, pass it on every operation for the session, reuse it only deliberately, and bind capture tokens/dialog IDs to the original browser_token. This goes well beyond the schema's basic pattern and description.

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

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

The actual purpose is stated late: "Create a new managed Chrome session, or explicitly reconnect to the session identified by browser_token." However, the opening sentence describes handling native dialogs, which is primarily sibling-tool territory and can mislead an agent about what launch_chrome itself does. The eventual create/reuse distinction is clear, but the purpose is buried and not front-loaded.

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 says to call launch_chrome without browser_token to create a new managed Chrome process, and to supply a token only to deliberately reuse the same session, including authorized handover. It also names when not to use it, such as never silently adopting another agent's browser and not being able to adopt ordinary Chrome windows. These are strong when/when-not/alternative signals.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the authorization requirement, the exact set of failure modes (uncaptured, stale, closed, replaced, already-handled, disconnected, mismatched text fails without acting), and the no-op behavior on text mismatch. That is exactly the behavioral context an agent needs before a mutating action.

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

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

The security requirement is front-loaded ahead of the mechanical rules, which is the right ordering for a mutating tool. Every sentence carries operative content, though the security preamble is lengthy and could be tightened without losing constraints.

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

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

For a 4-parameter, mutation-capable tool with no annotations and no output schema, the description covers preconditions, authorization, and failure modes thoroughly. The one gap is what a successful response returns or what post-dialog state results, which an agent would have to discover empirically.

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 50%, with prompt_text and browser_token documented in the schema but action and dialog_id not fully. The description compensates well by stating that prompt_text must be supplied explicitly for prompt+accept, that an empty string is an intentional empty submission, and that dialog_id must be one released by a successful capture. It adds real semantics beyond the enum and minimum constraints.

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 establishes a specific verb and resource (responding to a captured browser dialog) and explicitly distinguishes itself from the sibling task of capturing via get_captured_dialog. It never states a plain one-line summary of the operation, choosing instead to lead with the security precondition, so the purpose is inferable rather than stated outright.

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

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

Gives an explicit ordered precondition (first call get_captured_dialog and examine URL, type and message), an explicit prohibition (never accept merely to unblock automation or because the page asks), and the specific condition selecting prompt_text per action and dialog type. Alternatives and exclusions are fully enumerated.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it states the capture is single-use, requires a connected observer and no pending dialog, and explains that every opening in the Chrome instance counts, including other tabs/windows and replaced dialogs, while separate managed sessions do not. It also specifies capture_id retention and the expected follow-up 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 purpose is front-loaded and most sentences add actionable information about prerequisites, fallback behavior, and capture scope. The description is dense and somewhat long for a one-parameter tool, but it avoids obvious redundancy and keeps the critical instructions together.

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

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

For a tool with no output schema and no annotations, the description covers timing, prerequisites, failure handling, capture scope, and the follow-up call get_captured_dialog. It does not explicitly describe the return value or failure response of start_dialog_capture itself, but it provides enough context to invoke and use the tool correctly.

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

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

There is only one parameter, browser_token, and schema description coverage is 100%, so the schema already supplies the parameter syntax and meaning. The description reinforces the session scope but does not add new semantic detail about the parameter beyond what the schema provides.

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

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

The first sentence states a specific verb and resource: starting a single-use observation interval in the browser_token session immediately before a dialog-producing operation. It distinguishes the action from follow-up siblings by directing the agent to call get_captured_dialog afterward and to use only the specified fallback path for Windows Computer Use failures.

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

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

The description gives explicit timing guidance (immediately before an anticipated dialog-producing operation) and prerequisites (connected observer, no already-pending dialog). It also names alternatives and checks: get_dialog_status for no_dialog, get_window_state for fresh observation, and get_captured_dialog after the operation.

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