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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond annotations by disclosing that intent mode spends model quota and that --jev-decider controls whether Jev or the text model answers. It still does not describe side effects or what the operation returns, but it adds useful operational context.

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

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

The description is compact and front-loads the operation list before explaining target and intent modes. Every sentence contributes, though the final sentence is somewhat cryptic with 'Both' and '--jev-decider' requiring outside 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 five-parameter action tool with no output schema, the definition explains operation modes and target handling adequately. It does not explain how an observation is obtained, what the tool returns after acting, or how errors are surfaced, which leaves meaningful gaps for an agent planning a browser interaction sequence.

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

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

Schema description coverage is 100%, and the schema already documents text, intent, target, operation, and observation individually. The description mostly restates those semantics, reinforcing that CLICK/TYPE_TEXT/SELECT take a target and SCROLL/WAIT do not, but it adds little beyond the schema itself. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: run one operation on one target from an observation, with an explicit list of supported operations. It is clear what the tool does, but it does not differentiate itself from siblings such as browser_eval or browser_goal, leaving the agent to infer the boundary.

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 clearly explains the two modes: explicit operation plus target, or omit both and provide an intent for the policy to choose. It also specifies which operations need a target and that TYPE_TEXT may take text. However, it gives no guidance on when to use this tool instead of sibling tools like browser_eval or browser_page.

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 destructiveHint annotation only flags that something is destroyed; the description specifies exactly what (the owned tab and its daemon) and, crucially, what is spared (the shared browser other sessions may still be driving). That is context annotations cannot convey and it prevents a damaging misread of blast radius.

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

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

Two sentences, no filler. The action comes first and the safety boundary second, which is the right order for a destructive operation.

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?

There is no output schema, but for a zero-parameter teardown call there is nothing to return and nothing to configure. The description covers the action, the scope, and the side effect on the shared browser, which is everything an agent needs.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter claims are made or needed.

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

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

States a specific verb and resource (close the tab, stop its daemon) plus the ownership scope ('this session owns'), which cleanly separates it from sibling session-management tools like browser_open. An agent can pick this without opening any schema.

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

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

The sentence 'The browser this session attached to is never closed' implicitly tells the agent when this is appropriate: per-session tab teardown, not full browser shutdown. It doesn't explicitly name an alternative for closing the whole browser, so it stops short of full routing 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?

Discloses the critical, non-obvious trait that each read *drains* the buffer, which shapes call ordering in a way annotations (readOnlyHint, openWorldHint) cannot express. That single sentence prevents a real failure mode (losing diagnostics by reading too early).

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

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

Two tightly written sentences with no filler; the scope of returned data is front-loaded ahead of the drain warning and usage hint.

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

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

For a zero-param, no-output-schema tool, the description covers what comes back and how to time the call. It does not describe the shape/volume of the returned payload (e.g., truncation or ordering), a minor remaining gap.

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

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

The tool takes zero parameters and the schema is trivially complete, so the baseline is high. The description adds no parameter detail because there is none to add.

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?

Specific verb (read) plus a precise enumeration of the resource: console messages, uncaught exceptions, and failed/4xx-5xx requests. An agent can immediately distinguish it from browser_page (DOM content) or browser_eval (executes code).

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?

"Read it after reproducing a problem" gives a clear timing condition for invocation. It stops short of naming an alternative or exclusion (e.g., when to prefer browser_doctor for environment diagnostics), so it isn't fully explicit routing 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?

Annotations declare readOnlyHint=false, and the description justifies that by explaining that install: true builds a missing engine environment and waits for completion. It also discloses that the tool reports fixes for missing items. It does not cover permissions or possible side effects beyond the install, but the key mutation behavior is clear.

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

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

The description is front-loaded with the core reporting purpose, then gives the failure scenario and the install exception. The long enumeration is useful but makes the first sentence dense; overall it is efficient with no irrelevant content.

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

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

With no output schema, the description compensates by listing the diagnostic categories the tool reports, including versions, environment, browser, attach target, configuration, and fixes. Combined with the install behavior and failure-triage guidance, an agent has enough context to call 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 100%, and the schema already explains that install builds a missing environment or retries a failed install and returns when done. The description reinforces this but adds no meaningful syntax or semantic detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific diagnostic verb and resource: report what the browser tools need and whether it is present, enumerating interpreter, engine, harness, environment, browser, attach target, config, and fixes. This clearly distinguishes browser_doctor from action siblings like browser_act or browser_open, which perform browser work rather than diagnose the setup.

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 an explicit usage rule: 'Call it first when browser work fails.' That is strong guidance for the primary scenario. It does not state when not to use it or name alternatives, but no sibling appears to serve the same diagnostic role.

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 context beyond the annotations: output is capped, a thrown error returns as text, there is no user gesture, the call produces no observation, and browser_page must be called before the next browser_act. The single-CDP-connection constraint and the Chrome 144+ permission race are exactly the kind of operational hazard annotations cannot express.

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 and return shape are front-loaded in the first sentence, and the operational warnings follow. Sentences are dense and long, but each carries distinct information; a slightly tighter phrasing of the second-driver warning would help.

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

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

With no output schema, the description carries the return contract itself (string as-is, other values as JSON, capped) and explains state sequencing after the call. For a tool annotated destructive and open-world, the side-effect and session constraints are fully covered.

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

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

Schema description coverage is 100%, so both expression and timeout_ms are already documented, and the description does not restate or extend timeout semantics. It adds related context (no user gesture, error-as-text) but nothing about parameter formats beyond the schema, so baseline 3 applies.

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

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

States a specific verb (evaluate) plus resource (one JavaScript expression in the page this session owns) and defines the return contract. It is clearly distinguishable from browser_act ('the indexed action space') and browser_page, so an agent can pick it without opening the schema.

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

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

Gives concrete selection criteria: use for a programmatic read the indexed action space cannot express, or a one-off DOM operation. It also warns against starting a second CDP client. It stops short of explicit 'do not use this for X, use browser_act instead' routing, but the context is clear.

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

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

Adds substantial behavior beyond the annotations: the policy selects operations and targets autonomously, it consumes model quota, it runs isolated in a new tab, and the call returns a trace. Annotations already flag destructiveHint/openWorldHint, so the description does not need to repeat them, though it never warns that the autonomous policy may take irreversible web actions.

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

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

Two sentences, front-loaded with what the tool does and what it returns, with no padding. The trailing clause about --jev-decider is poorly anchored and slightly muddies an otherwise tight description.

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

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

With no output schema, the description correctly says a trace is returned, and it covers autonomy, quota cost, and isolation — the key facts for a non-idempotent, destructive open-world tool. It could still say more about failure/timeout behavior or how long a run may take.

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 both parameters (url, goal) are already documented in the schema, so the description adds no new parameter meaning. The mention of '--jev-decider' is not a schema parameter, which risks confusing an agent into trying to pass it as an argument.

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 concrete verb and resource: it runs one goal through the browser policy in its own tab and returns the resulting trace. The phrase 'in its own tab' and 'the page this session already has open is left untouched' distinguishes it implicitly from browser_act, though it never names a sibling 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?

The isolation detail ('left untouched') and quota cost imply this is for autonomous, self-contained multi-step goals rather than direct page manipulation. However, there is no explicit 'use this instead of browser_act when…' statement or exclusion, leaving the agent to infer the boundary with browser_act and browser_page.

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 openWorldHint, idempotentHint=false and destructiveHint=false, but the description adds details absent from them: the browser and its logins persist across calls, and the prior tab is closed on each open. That tab-closing side effect is exactly the kind of state change an agent needs to know. It stops short of 5 by not covering navigation failures, popups, or auth prompts.

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 tight sentences with zero filler. The key constraints (session ownership and tab replacement) are front-loaded, and the return value is stated in the same breath.

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

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

With no output schema, the description usefully explains that the call returns an indexed action space, and it covers the session-persistence model. Remaining gaps (error behavior, how the indexed action space is consumed) are minor for a one-parameter tool.

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

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

There is a single parameter with 100% schema coverage, and the schema already documents that it must be an absolute http(s) or file:// address. The description adds no syntax or format guidance beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource (open a page) plus scope: the browser owned by this MCP session. It clarifies what is returned (an indexed action space) so the agent knows this is not a pure navigation call. It does not explicitly differentiate itself from siblings like browser_page or browser_act, keeping it just short of a 5.

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

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

Usage is implied by 'open a page' and 'the previous tab is closed first', which hints at a one-page-at-a-time workflow. However, it never says when to choose this over browser_page (inspect) or browser_act (interact), and gives no prerequisites or exclusions.

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

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

Annotations already cover read-only and open-world, so the bar is lower, and the description adds real value: the call bumps an observation number while keeping the same indexed action space, meaning prior references stay valid. It doesn't explain what happens if nothing changed or whether any latency/limit applies.

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 what it does, then when to use it. Every clause carries information; nothing is 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?

With no output schema, the description supplies the essential return semantics (new observation number, same action space), which is what an agent most needs. Missing only edge-case behavior such as whether a re-read triggers navigation or waiting.

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

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

Zero parameters, so the baseline is 4. The description correctly frames this as a parameterless re-observation, and the empty schema is consistent with that.

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 concrete action and resource ('Read the current page again') and clarifies the result is the same indexed action space under a new observation number, which separates it from browser_act or browser_screenshot. It doesn't name those siblings explicitly, so the differentiation is implied rather than stated.

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 triggers: the page changed on its own, or an action was refused. That is actionable guidance, though it doesn't state exclusions (e.g. use browser_screenshot when you need pixels, or browser_act when you want to act rather than observe).

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 and openWorldHint, so safety is covered. The description adds a genuinely useful behavioral detail (target boxes and page structure are not rendered), but says nothing about return format, timing, or whether it waits for the page to settle.

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, zero waste, with the core action front-loaded and the caveat immediately after. Nothing redundant with the title or annotations.

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 tool with a self-evident action and read-only annotations, the description covers what is captured. The only remaining gap is the return shape (image payload vs. reference), and with no output schema that would have been a useful addition.

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

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

Zero parameters, so the baseline is 4. The description still earns it by making clear the capture is viewport-only with no full-page or element-selector options, telling the agent not to look for such 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?

Specific verb and resource ('Capture the visible viewport as an image'), and the second sentence clarifies scope by excluding drawn overlays. It implicitly contrasts with browser_page (which surfaces page structure) but never names a sibling.

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

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

Usage is only implied: the note that page structure isn't drawn in hints that browser_page should be used for structural/textual inspection, but there is no explicit when-to-use or when-not-to-use guidance among the eight siblings.

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