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

With no annotations at all, the description still discloses the important behavioral facts: the browser is headless, it auto-expires, and it has a default and maximum lifetime. It also carries a useful negative constraint ('Do NOT pass cdp_url here'). It stops short of stating concurrency limits, whether creation is metered, or what a failure looks like, so not a 5.

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?

Action statement is front-loaded, then a tight bullet list where each line maps to a distinct return field and its correct use. No filler sentences, and the expiry caveat sits last where it belongs.

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, so the description correctly takes on the job of documenting browser_id, connect_command, connect_url, cdp_url, and live_view_url — including the crucial warning not to interchange the URLs. That makes it callable and consumable. It lacks only edge-case behavior such as limits or error conditions.

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

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

Schema coverage is 100% for the single timeout_seconds parameter, and the description merely restates the default 1 hour / max 24 hours already written in the schema. Baseline 3 is appropriate — the schema does the work and the description adds no new parameter semantics.

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?

Opens with a specific verb+resource: 'Create a headless Chrome browser instance.' That is unambiguously distinct from the siblings list_browsers, delete_browser, and file-retrieval tools, so an agent can route correctly 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?

Usage is implied by naming — create a browser when you need one — and the description gives good downstream guidance on which returned handle to use for which client (agent-browser vs Playwright vs user sharing). However, it never states when to reach for this tool versus an existing browser session, and gives no exclusions or preconditions for creation.

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. 'Destroy' signals a destructive, likely irreversible mutation, which is useful, but nothing is said about whether associated files/artifacts are removed, whether active sessions are terminated, required permissions, or behavior when the ID is invalid.

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

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

One short sentence, front-loaded with the action and resource, with zero filler. Nothing is redundant or buried.

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 one-parameter tool with full schema coverage, the description is minimally adequate. However, as a destructive operation with no annotations and no output schema, it should disclose irreversibility and side effects on the browser's files or sessions.

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 browser_id parameter is fully documented in the schema (100% coverage), so the description adds little. Baseline 3 applies when the schema does the heavy lifting.

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 pair ('stop and destroy') and a specific resource ('browser instance'), so an agent knows exactly what the tool does. It doesn't explicitly differentiate from siblings like create_browser or list_browsers, though the delete semantics are self-evidently distinct.

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

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

There is no guidance on when to call this versus alternatives, no prerequisite checks (e.g., confirm the browser exists), and no mention of what to do if the instance is still in use. The agent must infer all usage context.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the URL embeds an auth token (a security-relevant trait), that a file-state object is returned alongside the URL, and the hard lifetime constraint that files only exist while the browser is alive. These are behaviors an agent cannot infer from the schema.

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

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

Four short sentences, action stated first, then return shape, then usage, then the lifetime caveat. Every sentence contributes a distinct fact with no repetition.

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

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

No output schema exists, and the description compensates by explaining the return (URL plus current file state, with `ready` as the existence signal) and the token/lifetime caveats. An agent has everything needed to call it and interpret the result 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 both parameters are documented in the schema, so the baseline is 3. The description adds no syntax or format detail for `path` or `browser_id` beyond what the schema already says.

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 gives a specific verb+resource: 'Get a download URL for a file inside the browser sandbox.' That clearly separates it from list_browser_files, but it never names a sibling or explicitly contrasts scope, so it stops 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?

It states concrete usage contexts — hand the link to the user (e.g. clickable in chat) or fetch directly — and tells the agent to check `ready: true` before assuming the file exists. It does not state when to prefer list_browser_files instead, so no explicit alternative routing.

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

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

No annotations exist, so the description carries the full burden, and it discloses several non-obvious traits: the sandbox is ephemeral (files vanish when the browser dies), a CDP download-path prerequisite exists, and there is a race between downloadProgress "completed" and file readability with retry advice. It omits what happens on a nonexistent path or permission errors.

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 operation and default, then prerequisites and the timing caveat. Nearly every sentence earns its place; the redundant restatement of the default path slightly overlaps with the schema.

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, so the description should hint at the return shape; it says files are discovered but never indicates whether entries are names, paths, or sizes. Everything else an agent needs to call it correctly — location, prerequisite, retry behavior — is present.

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

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

Schema coverage is 100%, including the default (/tmp/downloads) for path, so the schema already does the heavy lifting. The description reinforces the default path but says nothing about the glob `pattern` parameter or how results are ordered, adding no meaning beyond the schema.

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

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

States a specific verb and resource ("List files inside the browser sandbox") with the default location, so the operation is immediately identifiable. It does not explicitly contrast with the closest sibling, get_browser_file_url, though the scope difference (listing vs. retrieving a URL) is implied.

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 clear situational guidance: "Use after a download completes to discover what was saved," plus the prerequisite of pointing downloads at /tmp/downloads via CDP Browser.setDownloadBehavior. It does not name an alternative tool or a when-not condition, but the context for invoking it is unambiguous.

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

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

No annotations exist, so the description carries the full burden, and it does disclose the return shape: each item carries cdp_url, live_view_url, and connect_url/connect_command for running browsers. It also discloses the filter (only active instances) and the pro tip that connect_command can be executed directly. Missing only minor traits like ordering or whether stopped browsers ever appear.

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 it lists, then immediately the payoff (identity with create_browser's connection info) and the actionable conclusion. No sentence is 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?

There is no output schema and no annotations, so the description must explain returns — it does, describing the per-item fields and the distinction between running browsers and the rest. A note on what identifies each entry (name/id) or ordering would close the remaining gap, but an agent can call this correctly as written.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly keeps its focus on return values instead of inventing 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?

States a specific verb and resource ("List all active browser instances") with a scoping qualifier ("active"). It also names create_browser as the source of the identical connection fields, which lets an agent relate it to a sibling, though it doesn't explicitly contrast with list_browser_files or the delete tool.

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

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

Gives a concrete second use case — as a reconnect path via connect_command — which is real guidance an agent can act on. It stops short of stating when not to call it or naming alternatives to pick instead, so it is clear context without explicit exclusions.

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