AIHawk

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it scrolls the element into view and waits for it to be clickable, and it explains the main/support browser isolation. It omits failure behavior (selector not found, timeout limits) and any return indication, but the core interaction semantics are covered.

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?

Front-loads the action, then the behavior, then the alternative tool, then the parameter caveat. Four short sentences with no filler; each 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?

Output schema exists, so return values need not be described. Combined with the disclosed wait/scroll behavior and browser isolation, the definition is nearly complete; only error/timeout handling is left implicit.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it clarifies first-match semantics for the selector and states that browser defaults to `main` while `support` is fully isolated. Only a brief note on selector syntax (CSS) is missing.

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 (click) plus resource (first element matching a CSS selector) and explicitly differentiates itself from the sibling browser_click_at. An agent can pick between the two without opening either schema.

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

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

Gives an explicit alternative and the condition that selects it: when no selector can describe the target, use browser_click_at with coordinates from browser_snapshot. It also clarifies the browser parameter default and that main/support contexts share nothing.

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 pointer-movement sequence (move, then down, then up, with hold), the return value (screenshot after release), the silent-failure behavior (nothing raises, the click lands on whatever is there now), and the isolation between main and support browsers.

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?

Front-loaded with the core action and the differentiator, then the mechanics, then the staleness caveat, then the browser note. Dense and largely waste-free, though the multi-clause sentence structure is on the longer side.

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-param a tool with no annotations and no output schema, the description covers action, alternatives, movement sequence, return value, failure semantics, coordinate frame, and browser isolation. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it defines x/y as viewport-relative (not page-relative), explains hold_seconds as press-and-hold, and clarifies browser defaults to main with no shared state between the two. Every parameter gets meaningful semantics 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?

States a specific action (click/press-and-hold at a raw viewport coordinate) and explicitly contrasts it with the selector-based approach, so the agent can distinguish it from browser_click. The parenthetical examples (slider track, canvas captcha, precise point in a wider element) sharpen the distinction further.

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 explicit when-to-use (targets a selector cannot reliably reach) and an explicit alternative with preference ordering: 'prefer browser_click with the element's selector whenever it has one.' It also names the condition that invalidates cached coordinates (anything that scrolls) and the remediation (take a fresh snapshot).

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?

Without annotations, the description carries the full burden and delivers crucial behavioral context: the page is destroyed, other browsers are unaffected, and identity is forgotten so reopening creates a new session. This covers side effects, scope, and a deliberate state-loss behavior that an agent could not infer otherwise.

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?

Efficiently organized: first sentence states the action, subsequent sentences explain the effects. No wasted words, though the identity-forgetting elaboration could be marginally tightened.

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?

A simple one-parameter tool with an output schema. The description thoroughly explains the behavioral impact, including subtle identity loss. However, it is incomplete regarding the parameter's meaning and default behavior, which an agent needs 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 0%, and the description never mentions the 'browser' parameter, its enum values ('main', 'support'), or the default null behavior (which likely means closing the active browser). The parameter remains completely 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?

States a specific verb (close) and resource (browser), and clarifies the scope: it closes one browser, leaving the other sibling browser untouched. This distinguishes it from browser_open and other siblings, though it doesn't explicitly name which browser name is used.

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

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

The description implies this is for ending a browser session, but gives no explicit guidance on when to use this versus simply stopping interaction or leaving the browser open. No prerequisites or alternatives are mentioned.

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 thoroughly: it declares read-only enforcement, describes the refusal mechanism, names the mutating calls that trigger it, and even discloses the guard's limitation ('catches the obvious spellings, not every possible one') with guidance to report rather than exploit a bypass. This is unusually rich behavioral context for an unannotated tool.

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

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

Purpose is front-loaded in the first line, followed by the differentiating examples. The refusal paragraph is slightly repetitive across its sentences, but each clause carries distinct guidance (what is refused, why, what to use instead, and the guard's limits), so it mostly 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?

Return values are covered by the output schema, and the description fills the remaining gaps: safety profile, alternative routing, the main/support browser distinction, and the guard's imperfection. For a 2-parameter unannotated read tool, 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 coverage is 0%, so the description must compensate. It documents `browser` well (defaults to main, support shares nothing), but `expression`'s format and expectations are only implied through prose about what the script should do, not explicitly specified.

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

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

States a specific verb (read via JavaScript) and resource (the page), and immediately distinguishes itself from siblings by naming what it alone can see: 'a computed style, a value held in a framework's state, the length of a list.' An agent can tell it apart from browser_read_text, browser_read_html, and browser_snapshot 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?

Gives explicit when-to-use ('for what the other tools cannot see') and when-not (acting on the page is refused), and names the exact alternatives for the write case: browser_click, browser_type, browser_select_option. Nothing about tool selection 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?

With no annotations, the description carries the burden and does well: it explicitly states the tool starts nothing and is side-effect free, and clarifies that a non-running browser is "declared and not needed yet" and will be started by the next command aimed at it. It omits any auth or concurrency caveats, but the non-mutating contract is clearly disclosed.

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

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

The answer is front-loaded with what the tool reports, and the sentences are dense with real information. Phrasing like "which one the commands that name none go to" is awkward, and enumerating return fields partly duplicates the output schema, but overall little is wasted.

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

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

For a zero-parameter, read-only listing tool with an output schema, the description covers purpose, the non-mutating guarantee, and the semantics of "not running" — more than enough to call it correctly. The only gap is the unresolved boundary with the browser_status sibling.

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 the baseline is 4. The description adds no parameter meaning because there is none to add, and the empty schema is fully consistent.

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 concrete resource (the two browsers, their location/state, and the default focus target) rather than restating the name. An agent can tell it enumerates browsers and reports which one unnamed commands target. It does not, however, differentiate itself from the sibling browser_status, which likely overlaps.

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?

"Starts nothing: it reports what is running, so asking is free" implies this is a safe, cheap read to call when you need to know current browser state. But there is no explicit when-to-use versus browser_status or any of the other read-oriented siblings, leaving the agent to infer the split.

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, so the description carries the full burden and does so well: it discloses that the response reports the HTTP status and the actually-landed URL, warns that redirects to login walls or regional domains appear there, and flags that a 404/403 still returns a document that should not be read as content. It also states the default wait_until and that the two browsers share nothing.

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?

Purpose is front-loaded, then behavior, then parameter semantics. Four short paragraphs with essentially no filler; each sentence adds a distinct piece of operational value.

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

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

Despite an output schema existing, the description usefully explains return semantics while covering defaults, parameter behavior, and failure modes. The only meaningful gap is the absence of any routing against browser_open.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: wait_until gets its default and per-value meaning, and browser gets its main/support distinction plus isolation semantics. Only url is left unexplained, which is self-evident.

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 ('Go to a url in this browser's page') and adds the conditional 'opening it if none exists,' which hints at how it differs from browser_open. It never names the sibling, though, so an agent must infer the boundary between navigate and open.

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?

Offers strong guidance on parameter choice (when to use domcontentloaded vs load vs networkidle) and on browser isolation, but says nothing about when to choose this tool over browser_open. Usage guidance is parameter-level, not tool-selection-level.

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 reopening a live browser discards prior state ("what it held is gone"), that `support` is ephemeral and not saved, that the two identities share nothing, and how proxy defaults are inherited. It does not cover failure modes or permission requirements, so it stops short of 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?

Front-loads the main/support distinction before the reopening caveat and the parameter glossary, and each sentence carries information. It is dense rather than padded, though the parameter list is slightly verbose given the tool's inherent complexity.

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

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

For a 4-parameter tool with no annotations, no required params, and 0% schema coverage, the description covers all parameters, destruction/persistence behavior, and defaults. An output schema exists, so return values need not be explained here.

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

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

Schema description coverage is 0%, so the description must compensate and it does: seed (identity determinism, random when omitted), profile (persists cookies/logins/seed, "" means none), and proxy (full URI syntax, "" meaning, default inheritance from main) are all explained with semantics beyond the bare types.

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

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

States a concrete verb (Open/reopen) and the two named resources (main, support), and defines what each identity is. It also names the sibling browser_close for the complementary action, so an agent can place it in the toolset 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 explicit when-to-use guidance: open `support` when the task needs a second identity, and close it with browser_close as soon as the task no longer needs it, before answering. It names the alternative tool and the condition that selects it.

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

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

With no annotations, the description carries the burden and does add real context: keyboard targets the currently focused element, valid key string syntax ('Control+a', single characters), and the important fact that main and support browsers 'share nothing' (no shared session state). It omits failure behavior or what happens if nothing is focused.

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, no filler, with the scoping/state-isolation caveat front-loaded alongside the default. 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?

Output schema exists so return values need not be described. For a two-param tool the description covers key syntax and browser scoping adequately; only the focus prerequisite and error behavior are unstated.

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 – and it does for both params: it enumerates accepted key value syntax and explains the browser parameter's default ('main unless you say support'). The 'share nothing' note adds semantics not present in 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 (press) and resource (a key) plus the exact target semantics ('whatever has focus'), and enumerates concrete key formats. An agent can distinguish it from browser_type (bulk text entry) and browser_click 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?

Implies usage via 'whatever has focus' and clarifies the browser default, but never states when to prefer this over browser_type or browser_click, nor that focus must first be established. Usage is inferable rather than 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?

With no annotations, the description carries the full burden and does so well: it discloses the critical trait that output is NOT capped and can be 'tens of thousands of characters', explains why it is not truncated (broken tags), and warns that `main` and `support` browsers 'share nothing'. These are exactly the behaviors an agent needs before invoking.

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?

Front-loads the identity of the tool in the first line, then adds modes, then size caveat, then routing. Dense but every sentence carries distinct decision-relevant information; 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?

An output schema exists, so return values need not be described. For a 2-param, zero-required read tool, the description covers purpose, mode semantics, browser context isolation, output size expectations, and sibling routing - nothing material is missing.

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

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

Schema description coverage is 0%, so the description must compensate and does: it defines all three `mode` values (form = interactive surface plus explanatory text, text = prose alone, full = structure minus attribute soup) and clarifies `browser` defaults to main and that the two browsers are isolated. This is meaning the schema does not provide.

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 ('the page's HTML, cleaned down to what is worth reading') and immediately frames the differentiator: structure preservation versus browser_snapshot's flat clickable inventory. An agent can distinguish this from browser_read_text and browser_snapshot 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?

Gives an explicit selection rule ('Use this when the STRUCTURE matters - a form and its labels, a table, what a control is wired to') and names the alternatives with their selecting conditions: browser_snapshot 'when you only need something to click', and a direct contrast with browser_read_text on capping.

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, so the description carries the full burden, and it does well: it discloses truncation behavior, the default limit, how truncation is signaled in the output, and the browser isolation semantics ('they share nothing'). Missing: nothing about permissions, timing, or what happens if the selector matches nothing, which a read tool could usefully state.

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?

Front-loaded with the one-line purpose, then routing, then truncation, then environment. No sentence is filler, and each paragraph adds a distinct fact an agent needs.

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

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

An output schema exists, so the description needn't explain return values, and it correctly focuses on scoping, truncation, and environment isolation. For a zero-annotation, zero-covered-schema tool, this is as complete as a description can be.

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, and it does: it explains selector narrowing, clarifies max_chars and its 6000 default with truncation marking, and explains the browser default ('main unless you say support') plus the isolation semantics. The only gap is that neither source documents what the selector syntax accepts.

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 operation (read the visible text of an element, markup stripped), which is clearly distinct from sibling browser_read_html (structure) and browser_snapshot (clickable elements). An agent can route between the three read tools 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?

Explicit when-to-use and named alternatives: 'Narrow the selector when you know where the answer is; use browser_read_html instead when the structure matters, or browser_snapshot when you need something to click.' This is exactly the routing guidance the sibling set demands.

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

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

With no annotations, the description carries the behavioral burden and does a good job: it discloses that this triggers a genuine page-visible interaction unlike browser_evaluate, and it explains the browser-scoping rule ('main' default, 'support' shares nothing). It doesn't say what happens when the option is absent or how it waits for readiness, so it stops short of full 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?

Three short paragraphs, front-loaded with the core action, then the alternative-selection reasoning, then the browser-scoping caveat. Every sentence carries information; 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?

For a 3-parameter tool with an output schema (so return values need no explanation), the description covers purpose, alternatives, and the browser parameter's semantics. Failure behavior (option not found, timing) is the only notable omission.

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 clarifies that `value` matches either the visible label or the underlying value, and explains `browser` (main vs support, isolated state). Only `selector` is left to inference as a standard CSS selector.

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 (choose) and resource (option in a `<select>` dropdown) plus the two accepted addressing modes (visible label or value). An agent can immediately distinguish this from generic siblings like browser_click or browser_evaluate.

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 names the alternatives (clicking the dropdown plus arrow keys, and browser_evaluate) and gives the reason each is inferior — arrow keys can't confirm which row landed, and evaluate sets the value without a real page interaction. This is explicit when-to-use/when-not guidance.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: selectors are guaranteed unique-matched while raw selectors often aren't, elements without a selector expose centre coordinates, and the `browser` contexts 'share nothing'. It omits the read-only nature and any rate/limit caveats, but adds substantial context beyond the schema.

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

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

Purpose is front-loaded and the paragraph breaks separate distinct concerns. It is somewhat long and the 958-element / 88% vs 48% statistics are heavy editorializing, but each block still carries actionable 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?

An output schema exists, so return values needn't be re-explained, yet the description usefully characterizes them anyway. For a 2-parameter read tool the coverage is good; only `max_chars` semantics and an explicit read-only statement are missing.

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

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

Schema description coverage is 0%, so the description must compensate. It handles `browser` well ('main unless you say support, and they share nothing'), but only alludes to `max_chars` via 'the character cap' without explaining the parameter's unit, default, or truncation 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 first sentence names the resource precisely: title, url, and the visible interactive elements. It further differentiates by ruling out the accessibility tree, so an agent can tell it apart from browser_read_html/browser_read_text. No explicit verb, but the resource and scope are 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?

It routes the caller downstream (pass `selector` to browser_click/browser_type, use `at` with browser_click_at) and excludes the accessibility tree, but never states when to prefer this over sibling readers like browser_read_text or browser_take_screenshot. Usage is implied rather than declared.

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 well: it discloses that the tool starts nothing, that it reports the absence of a browser rather than failing, and that the returned seed is the reusable handle for browser_open. It does not cover error/permission behavior, but for a non-mutating status probe that is minor.

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 substantive facts are front-loaded in the first line and the browser-namespacing rule is placed last where it is easy to find. The prose is somewhat ornate ('the exit, the profile and the page'), which costs a little density, but no sentence is wasted.

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

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

An output schema exists, so return values need not be documented, yet the description still summarizes what comes back, and it also covers the no-browser-running case and the main/support isolation rule. Combined with a single optional parameter, an agent has enough to invoke it correctly; only lifecycle/permission edge cases are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does: it states the default ('browser is main unless you say support') and the critical semantic that the two browsers 'share nothing.' It does not spell out the enum values as explicitly as it could, leaving the exact accepted strings to 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?

The opening line names the verb and resource concretely: reporting the current browser identity, exit, profile and page. It clearly differentiates from the mutation siblings like browser_open and browser_close by stating 'It starts nothing.' The only gap is that it never contrasts itself with browser_list, which an agent could plausibly confuse it with.

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 trigger ('Ask whenever you need to know which person the browser currently is, or from where its traffic leaves') and a secondary use case (recording a seed for later reuse via browser_open). It does not state when *not* to use it or name an alternative for enumerating browsers, 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?

With no annotations, the description carries the full burden. It adds a genuinely useful behavioral fact — 'main' and 'support' browsers 'share nothing' — and implies a single one-shot capture, but says nothing about the return format (image, base64, file path) or any side effects.

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 followed by the parameter note. Nothing is padded or redundant beyond the mildly decorative 'on demand'.

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-optional-parameter capture tool with no annotations and no output schema, the definition covers parameter semantics and browser isolation but omits what the tool actually returns and any precondition (an open/navigated page). Adequate but with a real gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it gives the default for 'browser' ('main unless you say support') and clarifies the isolation semantics between the two values. It covers the only parameter's meaning well.

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 ('One screenshot of this browser's page'), which distinguishes it from siblings like browser_snapshot, browser_read_text, and browser_read_html. It stops short of explicitly naming the sibling it differs from, but the intent 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?

'On demand' is the only usage cue and it is vague; it does not explain when to prefer this over browser_snapshot or browser_read_html, nor does it give prerequisites such as needing an open page. No when-not guidance is offered.

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

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

With no annotations, the description carries the burden and delivers key traits: the value is set atomically rather than typed, keystroke handlers do not fire, and the two browser contexts ('main'/'support') share nothing. It still omits failure behavior (missing selector, timing/waiting), so not a full 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?

Front-loaded with the core action and the replacement semantics, then the alternative, then the browser-scope caveat. Every sentence earns its place, though the phrasing is slightly prose-heavy for the small amount of information conveyed.

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?

Output schema exists, so return values need not be explained. For a browser-automation input tool the description covers mechanism, alternative, and context isolation, but leaves selector syntax and error/timing behavior unspecified.

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% across 3 params, so the description must compensate. It explains the `browser` parameter well (defaults to `main`, `support` is isolated, no shared state) but adds nothing about `selector` syntax or `text` semantics, which remain undocumented everywhere.

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 action and resource ('Fill a field, replacing whatever it holds') and immediately contrasts the mechanism with key-by-key typing. An agent can distinguish it from browser_press_key and browser_click 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?

Names the explicit exception and the alternative for it: fields needing per-keystroke handlers (autocomplete) should 'click the field and use browser_press_key'. That is a when-not plus a named sibling, not just implied 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?

No annotations are provided, so the description carries the full behavioral burden, and it does substantial work: it starts nothing, refuses rather than opening a browser to photograph, and discloses that main and support share nothing. It stops short of describing the return payload (image format/size) or any rate or cost implications of a high-frequency capture.

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?

Front-loads what the tool shows, then the usage boundary, then the precondition. Prose is slightly literary ('a look is not a command') but every sentence carries distinct information and nothing is redundant.

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 read tool, it covers purpose, alternative, precondition, and parameter default/isolations. The main omission is what the returned capture looks like (image bytes vs encoded frame), which an agent might want before invoking repeatedly.

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 schema only carries the enum values, so the description must compensate. It does: it explains that `browser` defaults to `main` unless `support` is specified, and adds that the two are fully isolated, which is meaningful for a single optional 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?

States a specific resource and modality: the whole browser window as a person sees it, including tab strip, address bar, page and pointer, from a live capture. It explicitly distinguishes itself from browser_take_screenshot and browser_click_at, so an agent can tell what this returns 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 explicit when-to-use ('for watching the work'), when-not ('not for acting on it', 'do not feed its coordinates to browser_click_at'), and names the alternative (browser_take_screenshot). It also states the precondition behavior (refuses if no browser is running) and notes the live panes call it many times a second.

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