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 first-failure abort, that steps aiming by number are skipped after a page-changing step, and that a fresh snapshot is returned. It omits how a partial failure is reported back (which step failed, what state the tab is left in), which matters for a batch of up to 10 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?

Front-loaded with the purpose, then the usage rule, then the failure behavior, then an edge-case tip — a sensible ordering. Some phrasing is wordier than needed ('all aimed with the numbers of one snapshot', 'after a step the browser says changed the page'), but 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?

For a complex orchestrating tool with no annotations and no output schema, the description covers return value, ordering constraint, and abort behavior. The main gap is error reporting granularity on partial batch failure, which an agent would want before committing 10 steps to one call.

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 75% and already documents tabId/windowId/snapshotId/args, but the description adds the crucial coupling: all action numbers come from one snapshot, and a step may carry its own snapshot id in args. It does not restate the 10-action cap or the allowed tool enum, though those are 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?

Specific verb and resource: 'Run several page actions on one tab in a row ... then get a fresh snapshot back — one call instead of one per step.' It also names the mechanism (shared snapshot numbering) that distinguishes it from the individual sibling tools like browser_click or browser_input_text.

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 positive case ('tick two filters, fill three fields that are already on screen') and explicit negative case ('Do not put a step in that aims at something an earlier step makes appear') with the reason (the number does not exist yet). It even covers the degenerate case: 'Worth using for a single action too.'

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: the kernel re-queries the element's live position, refuses if the element is gone/moved/covered, and explicitly "does not pretend to succeed." It also discloses that x/y bypasses these safety checks.

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 the primary mechanism, then the fallback caveat. Every clause earns its place with 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 mutation tool with no annotations and no output schema, the description covers the critical behavior (refusal semantics, live-position check) well. Minor gaps remain around what a successful click returns or coordination with snapshotId freshness, but nothing an agent needs to call 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 100% and already documents all 8 params, so baseline is 3; the description adds real value on emsn persistence ("keeps its emsn while the page stays") and the x/y checks skipped, beyond the schema text. Other params (button, clickCount, tabId) are left 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?

States a specific verb (Click) and resource (an element by its emsn from the latest snapshot) and immediately distinguishes the two targeting modes (emsn vs x/y). An agent can tell exactly what this does 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?

"prefer emsn" and "Passing x/y instead skips all of that checking" gives a clear selection rule between the two targeting modes. It doesn't explicitly contrast against sibling tools like browser_move or browser_drag, keeping it shy of a 5.

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

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

With no annotations, the description carries the full burden and does disclose a real side effect: dismiss refuses without writing a decision into the browser profile, and by implication other actions do persist a decision beyond the task. That is a meaningful, non-obvious behavioral trait. It does not cover failure behavior when no popup is present or what the call returns.

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 tight sentences, front-loaded with the action, then discovery, then the safety caveat. Every sentence carries decision-relevant 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?

All parameters are optional with full schema documentation and no output schema, so the description need not explain returns. It supplies the discovery path and the persistence caveat, which is what an agent needs to act safely. Minor gap: no statement of what happens if no popup is actually blocking the tab.

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%, including the enum values and the dismiss default, so the schema already documents all three parameters. The description's 'use dismiss when unsure' restates the schema's 'Default dismiss, the most conservative one' rather than adding new semantics. Baseline 3 applies.

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

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

The description states a concrete verb+resource: answer/close a popup blocking a tab, with the parenthetical naming the concrete cases (permission bubbles, dialogs). It is clearly distinct from browser_take_snapshot, which it positions as the inspection tool. The only ambiguity is that 'answer' is broader than the tool name's 'close', though the parenthetical resolves it.

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 routes the agent: use browser_take_snapshot to learn which popups are open and what each accepts, then act here. It also gives an explicit safe default ('When unsure use dismiss'), which is exactly the when-in-doubt guidance an agent needs.

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 burden of behavioral disclosure, yet it says nothing beyond the action. It does not state whether closing is undoable, what happens when the last tab is closed (does the window close?), or whether the page loses 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?

The single short sentence is front-loaded and has zero waste. It is arguably over-compressed, but there is no filler or buried 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?

For a destructive, unannotated operation the description is too thin: it omits default behavior when no parameters are supplied, edge cases like the last tab, and side effects. The schema covers the parameters, but the behavioral picture an agent needs before closing a tab 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 100% and both optional parameters (tabId, windowId, with their defaulting behavior) are fully documented in the schema. The description adds no additional meaning, 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?

"Close a tab" names a specific verb and resource, so the basic action is clear. However, with siblings browser_close_window and browser_close_popup_bubble in the set, it offers no differentiation about what a "tab" is versus a window or popup bubble, leaving the agent to infer scope.

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

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

There is no guidance on when to use this versus browser_close_window, browser_close_popup_bubble, or browser_batch. Usage is only implied by the verb; no prerequisites, exclusions, or alternative routing are 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 burden, and it does disclose the key behavior that closing a window cascades to every tab and leaves other windows intact. However, it never states that the action is irreversible or that unsaved state in those tabs is lost, which is exactly the risk context an agent needs before a destructive call.

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 sentences: scope first, then non-effect on other windows, then sibling routing. Nothing is repeated and nothing 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 one-parameter action with no output schema and no annotations, the essential semantics (what is closed, what is spared, where to go for the narrower case) are all present. Only the irreversibility/data-loss warning 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 100% with a single required windowId already documented ('The window to close.'), so the schema does the heavy lifting. The description adds no extra semantics such as format, whether the ID is user-visible, or what error occurs for a stale ID, making baseline 3 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 ('Close a browser window and every tab in it') and immediately scopes the blast radius ('Other windows are unaffected'). It also names the sibling it must not be confused with (browser_close_tab), so an agent can choose correctly 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?

It gives an explicit routing rule: one tab → browser_close_tab, whole window → this tool. The 'other windows are unaffected' clause plus the alternative naming covers the realistic selection decision an agent faces.

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 does disclose a genuinely important behavioral trait: the far end is not auto-scrolled into view, which will silently break drags. It also notes that a stale emsn is refused rather than clicked. It omits what a drag returns or how failures surface, keeping it below 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?

Three tight sentences, front-loaded with the gesture and then the constraint, with the critical on-screen requirement bolded. 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?

For a 14-parameter tool with no annotations and no output schema, the description covers the highest-risk failure mode (off-screen endpoint) and the destination-mode ambiguity. Defaults for holdMs/settleMs and the return behavior remain undocumented, so it is strong but not exhaustive.

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%, so baseline is 3. The description does add real value by stating the destination must be given 'exactly one way' across three mutually exclusive modes (toEmsn, toX/toY, dx/dy) — a constraint the schema itself does not encode — but the remaining parameters (holdMs, settleMs, button, tabId, windowId) are left entirely 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?

Opens with a concrete verb sequence ('press on something, carry it somewhere, let go') and immediately differentiates from the sibling browser_click by naming the gesture a click cannot make. The enumerated use cases (sliders, canvas panning, split bars, reorderable lists) make the tool's domain unmistakable.

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 context for when to reach for this over browser_click and states a hard precondition: both endpoints must already be on screen, so scroll first. It stops short of naming browser_scroll as the explicit prerequisite tool, but the routing intent 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?

With no annotations, the description carries the full burden, and it does disclose the key ecosystem behavior: other tools operate on the frontmost window/tab by default, which reframes this tool as an opt-in orientation step. It stops short of saying whether the listing is cheap, whether popups/background windows are included, or what the exact return shape looks like.

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, zero waste: the first states what is listed and what identifiers come back, the second front-loads the decision guidance. Nothing redundant with the empty 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?

For a no-parameter, no-output-schema tool, the description covers both the content and the identifiers returned, which is the essential shape. Minor gap: without an output schema, it could say whether windows are ordered, whether popups/background windows appear, or how to act on the returned ids (e.g. select_tab).

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 mentions windowId and tabId, but those are return values rather than inputs, so there is no parameter meaning left 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 (list) plus resource (every browser window and its tabs) and it names the identifying fields returned (windowId, tabId). An agent can immediately tell this is a read-only enumeration of open windows, distinct from browser_status or browser_take_snapshot.

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 states the use case (find out what is open) and an explicit when-not: the other tools default to the frontmost window and tab, so you usually do not need to call this first. That routing guidance is exactly what an agent needs to avoid an unnecessary call.

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 one real behavioral trait: calling it when history is exhausted will fail, plus the precheck route. It says nothing about whether navigation waits for the page to load, whether the page's DOM is ready afterward, or whether state is preserved — meaningful gaps for a navigation 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?

Two sentences, no filler. The core action is front-loaded, and the operational caveat follows immediately. 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?

The tool is simple (2 optional params, no output schema, no annotations), so the description is close to adequate. But with no output schema, an agent is left guessing what a successful call yields or whether it blocks until the new page loads — the one remaining thing worth stating.

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 tabId and windowId are already explained with their defaults. The description's phrase 'this tab's history' loosely reinforces the tabId target but adds no syntax or defaulting detail beyond the schema. Baseline 3 is the correct ceiling here.

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 back one step in this tab's history.' The scope ('one step', 'this tab') is precise and clearly distinguishes it from navigation tools like browser_navigate or browser_reload. It never names browser_go_forward as the counterpart, so sibling differentiation is implied by the word 'back' rather than explicit.

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 actionable precondition and names the tool that answers it: 'browser_get_window_info reports whether a tab can go back.' That effectively tells the agent when to use versus when to skip. It stops short of explicit when-not-to-use framing or naming browser_go_forward as the alternative direction tool.

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

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

No annotations exist, so the description carries the full disclosure burden and drops it. It never says what happens when there is no forward history (error vs no-op), whether it blocks until the page loads, or whether it interacts with human-control state given sibling tools like browser_start_human_control.

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, front-loaded sentence with zero padding. It is efficient, though its brevity contributes to the missing behavioral detail rather than being a model of tight completeness.

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 history-navigation tool with no output schema and fully documented optional params, the core intent is covered. Edge-case behavior (no forward entry, load waiting, failure modes) is absent, which matters for an automation agent deciding whether to call it.

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% with two optional, well-described params (tabId, windowId defaults). The description adds nothing beyond the schema — it does not explain default resolution or ordering between tabId and windowId.

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+resource+scope: 'Go forward one step in this tab's history.' Unambiguous about what it does. No sibling differentiation is offered, but the pairing with browser_go_back makes the intent self-evident from name and description alone.

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

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

Usage is only implied by the word 'forward' and the history framing. It never says when to prefer this over browser_navigate, browser_reload, or browser_go_back, nor does it state any precondition (e.g., that forward history must exist).

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: it discloses that it types nothing when the field will not take focus, that it fails and lists locations on ambiguous/absent anchor matches, that it reads text back and fails if the editor reformatted it, and that clearText wipes an entire mail body including quote and signature. It also warns that Enter submits a form. These are exactly the failure modes an agent needs before calling a mutating UI 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?

The main action is front-loaded and no sentence is padding given 12 parameters and several input modes. However, phrasing like 'Fails, typing nothing, when the field does not take focus' is convoluted, and the middle paragraph packs anchors, escaping, ambiguity and read-back verification into a single dense block that is harder to scan than it needs to be.

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 annotations, no output schema, 12 parameters and multiple elements types—yet the description still covers targeting, defaults, failure modes, the verification-and-quote reply, and destructive side effects. Nothing an agent needs to call this safely 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 already 100%, so baseline would be 3, but the description adds real meaning on top: how to spell the anchor words from the snapshot value, that \n is a line break and ¤ marks kept escapes, that the ‸ caret and ⟦⟧ selection markers are ignored, and how occurrence resolves duplicates. That is operational detail absent from the schema text.

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?

A precise verb plus resource: 'Type text into an element by its number (emsn), or into whatever has focus when no emsn is given.' It goes further and enumerates the element classes it covers (SELECT, date/time/week/month/colour fields, editable areas), so an agent can match the tool to the target element 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?

It explicitly routes one case away from a sibling: 'Use this rather than clicking a SELECT: its list is not in snapshots.' It also clarifies the default path ('text goes in at the caret; the element is clicked first unless focus is already in it'). It does not distinguish itself from browser_press_key or browser_select_editable_text, so the guidance is strong but not exhaustive.

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 non-obvious traits that pages keep running at full speed, snapshots keep working, and browser_show reverses it. That is the critical distinction from closing a window; only permission/auth requirements are left unstated.

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 sentences, front-loaded with the action and purpose, then behavior, then the restore path. No filler and nothing repeated.

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 single-parameter, non-destructive action with no output schema and no annotations; the description covers what happens to the window, what keeps running, and how to undo it. Nothing an agent needs in order to call 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 100% and the single windowId parameter is already documented in the schema. The description adds minor meaning by clarifying the window is yours and contains all your tabs, but no format or lookup guidance. Baseline 3 is appropriate when the schema does the work.

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 (minimize) and resource (one of your windows), and clarifies scope with "every tab in it yours". This cleanly separates it from browser_close_window (destroy) and browser_show (restore), both of which appear in the sibling list.

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 the motivating context ("keep it out of a person's way while you work in it") and names browser_show as the inverse operation. It does not explicitly state when not to use it (e.g., when the window should actually be closed), so it falls short of a full when/when-not pairing.

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 disclose two useful traits: revealed content is unnumbered until a fresh snapshot, and the reply reports the final pointer position. It leaves out edge behavior such as off-screen elements or whether hover auto-scrolls.

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 sentences, verb-first, each carrying distinct information: what it does, the ordering constraint, and the return value. Nothing is repeated from 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?

For a lightweight pointer action with no output schema, the description covers purpose, ordering, and response shape adequately, and the schema handles parameter edge cases like stale emsns. Minor gaps remain around failure modes beyond the stale-element case.

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 emsn, x/y, tabId, windowId and the snapshot staleness rule are already documented in structured fields. The description adds only the workflow framing around snapshotId, not new parameter meaning; 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?

Opens with a concrete verb and target: 'Hover the pointer over an element.' The stated scenario (menus/tooltips that only appear under the pointer) implicitly separates it from browser_click, but no sibling is named explicitly, so an agent must 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?

Gives a clear when-to-use condition ('for a menu or a tooltip that only appears under it') and a sequencing rule ('hover first, then snapshot, then act'). It stops short of naming alternatives such as browser_click or stating when not to hover.

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 usefully discloses a real behavioral invariant (pre-navigation element numbers become void), which is valuable context for the snapshot/click workflow, but it omits whether the call blocks until load, what happens on navigation failure, or whether it errors versus returning a status.

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 action and followed immediately by the one non-obvious consequence. Nothing is redundant or padded.

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

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

For a 5-parameter navigation tool with no annotations and no output schema, the description covers purpose and the stale-element caveat but leaves the caller unsure about blocking semantics, failure modes, and what state the tab is left in. It is adequate, not complete.

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

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

Schema description coverage is 100%, so url, tabId, windowId, timeoutMs and waitUntil are already documented in the schema. The description adds no syntax, default, or interplay information beyond that, which is the expected baseline when the schema does the work.

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 URL in a tab"), which is enough to identify it as a navigation tool. It does not distinguish itself from sibling browser_new_tab or browser_reload, which are the nearest alternatives, so an agent must infer the difference.

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 explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer browser_new_tab or browser_reload instead. The phrase "in a tab" faintly implies reusing an existing tab, but this is never stated as a rule.

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 disclosure burden, and it only adds the return value ('Returns the new tabId'). It does not say whether the new tab steals focus, whether the call blocks until load completes, or how it interacts with existing tabs — meaningful gaps for a browser mutation.

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 with zero filler, and the core action is front-loaded before the return-value note. Nothing could be removed without losing information.

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

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

The schema fully documents all five optional parameters and the description supplies the missing return type, so the mechanics are covered. However, as a mutation-style tool with no annotations, the absence of any context about focus behavior, blocking, or sibling selection leaves it only minimally viable.

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%, with every parameter (url, windowId, timeoutMs, waitUntil, foreground) documented inline, so the baseline of 3 applies. The description adds nothing about parameter behavior beyond restating the return value.

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 ('Open a new tab') that an agent can immediately map to intent, and it implicitly separates the tool from browser_new_window and browser_select_tab. It stops short of explicitly differentiating itself from those closely related 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?

There is no guidance on when to use this tool versus browser_new_window, browser_navigate, or browser_select_tab, and no prerequisites or exclusions are given. An agent must infer that this is for creating a tab rather than navigating an existing one.

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 does disclose the return value ('Returns the new windowId'), which is valuable since there is no output schema, but it says nothing about side effects such as whether the new window takes focus, how incognito state persists, or whether hideWindow affects later calls.

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 action and followed by the return value. Nothing is wasted and nothing important is 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 three-optional-parameter tool with a fully documented schema, this is close to sufficient, and it correctly notes the returned windowId in the absence of an output schema. It stops short of clarifying the relationship to browser_new_tab and the window's focus/visibility behavior, which matter for correct invocation sequencing.

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 all three parameters (url, incognito, hideWindow) are documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, such as default visibility behavior or what happens when url is omitted.

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

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

States a specific verb and resource ('Open a new browser window'), which is unambiguous on its own. It does not, however, distinguish itself from the close sibling browser_new_tab, so an agent must infer the window-vs-tab distinction.

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

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

No when-to-use guidance and no mention of alternatives, despite a dense sibling set including browser_new_tab, browser_show, and browser_get_window_info. The agent gets no help choosing between opening a window and opening a tab.

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 largely succeeds: it discloses that refused key sequences result in nothing being pressed, that the call returns a reply only after the page handles the last key, and crucially that it does not report what the keys did — so a snapshot is needed. It also explains the arrow-from-highlighted-item gotcha that snapshots don't show. It does not mention focus requirements beyond 'where focus is' or error behavior for stale emsns (left to 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?

It is front-loaded with the core behavior, but the single sprawling sentence front-loads examples before stating the purpose plainly, and the 'before browser_input_text without emsn types there' clause is garbled and hard to parse. Information is useful but structurally crowded.

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 6-parameter interaction tool with no annotations and no output schema, the description covers the key behavioral risks: refused shortcuts, asynchronous completion, absent feedback requiring a snapshot, and the highlighted-item arrow caveat. The one gap is the lack of explicit mention of what is returned on refusal or how emsn staleness surfaces, though the schema covers emsn.

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 the schema already documents emsn, keys, repeatCount, tabId, windowId, and repeatDelayMs thoroughly. The description adds only a little beyond that — the ordering semantics ('in order') and the pointer-highlight interaction with arrows. Baseline 3 fits 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?

The description states a specific verb and resource — pressing keys in order at the current focus — and immediately distinguishes itself from browser_input_text ('Not for typing text'). The concrete examples (Escape, Tab, ArrowDown/Enter, Control+Z) make the intended use unmistakable, though the opening sentence is dense and the 'emsn' typo-ish phrasing slightly obscures the caret relationship.

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 explicit positive cases (close a dialog, move between fields, pick from a suggestion list), explicit exclusions (copy/cut/paste and browser shortcuts, routed to browser_close_tab/browser_reload), and a named alternative for text entry (browser_input_text). An agent knows exactly when to call this and when to call something else.

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: each URL opens in a background tab of an existing window, the whole page is read, the tab is closed, and nothing is left open. It also discloses return format, link notation, per-page character limits, continuation behavior, partial-failure isolation, and the captcha caveat for search URLs.

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?

Despite being a dense paragraph, it is front-loaded with the core purpose and the primary alternative, and every sentence adds operational value. There is no filler or 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?

For a no-annotation, no-output-schema tool with five fully described parameters, the description covers the return shape, size limits, continuation, tab lifecycle, partial failure, and search-engine caveat. An agent has enough information to call it correctly without opening the schema.

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 all five parameters are already documented in the schema. The description reinforces the 15,000-character limit and the read-on behavior tied to the `from` parameter, but adds little parameter-level syntax or nuance beyond what the schema already 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 description starts with a specific verb and resource: "Read web pages." It immediately distinguishes the tool from a built-in fetch tool and from browser_new_tab, which is for acting on pages, so an agent can tell exactly what this tool is for.

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

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

It explicitly says to use this instead of WebFetch, explains why (returns page text rather than a summary), and says not to use it for search-results URLs because of captchas. It also routes acting-on-page use to browser_new_tab, covering both when to use and when not to use 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 full burden. It does disclose one valuable behavioral trait — that previously captured element numbers are invalidated by the reload — but omits whether the call blocks until the page finishes loading, whether it bypasses cache, and whether unsaved form/input state is lost. For a state-mutating navigation tool this is a partial 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?

Two short sentences with no filler, and the invalidation warning is front-loaded immediately after the action statement so an agent reads it before acting.

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 two-optional-parameter tool with full schema coverage and no output schema, the definition is close to sufficient and captures the key gotcha about stale element references. The notable remaining gap is load-completion semantics — whether the tool returns before or after the page has loaded — which materially affects agent sequencing.

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 tabId and windowId are already fully documented in the schema, including their defaults. The description adds nothing about targeting semantics, 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?

"Reload the tab" gives a specific verb and resource, and is clearly distinguishable from siblings like browser_go_back, browser_go_forward, and browser_navigate. It does not explicitly name those alternatives, but the action itself is unambiguous.

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

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

Usage is only implied: an agent must infer that this is the tool to call when the page content needs refreshing rather than re-navigating. There is no explicit statement of when to prefer reload over browser_navigate or browser_go_back, and 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?

With no annotations, the description carries the full burden and does well: it discloses duration ('takes minutes, not seconds'), progress reporting, autonomous step planning, mid-task pausing on login/captcha/payment with human handoff and resumption, and the vision-model dependency. It does not clarify failure behavior or what happens when maxRounds is exhausted, which keeps it below 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?

Four sentences, each earning its place: purpose first, then duration expectation, then input style, then human handoff, then the model prerequisite and cheaper alternative. Nothing is repeated from the schema and the most decision-relevant facts are front-loaded.

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

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

Given an 11-parameter, long-running agentic tool with no annotations and no output schema, the description covers the important behavioral surface (duration, pausing, resumption, model requirement). The one gap is that with no output schema it never says what a completed run returns or how progress/errors are surfaced, which would matter for a caller parsing results.

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 91%, so the baseline is 3, but the description adds real meaning for the `task` parameter ('describe the task in plain language; it works out the steps itself') and explains the resume model that titles history/tabId/windowId/humanReply are used for. That goes beyond restating schema text.

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: 'Carry out a whole web task in a real browser and report what happened.' It explicitly frames the tool as end-to-end task execution rather than a primitive action, which cleanly separates it from the many browser_click / browser_navigate 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?

Gives explicit when-to-use ('a whole web task'), when-not-to-use ('for a small job you can drive the browser yourself'), the alternative siblings by name (browser_take_snapshot / browser_click / browser_input_text), and the prerequisite (vision model via EMBIODY_VLLM_*). It also documents the human-handoff path for login/captcha/payment.

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 burden. It discloses meaningful behavior: the tool replies only once scrolling is at rest, reports when it moved less than requested because of an end or page intervention, and invalidates coordinates afterward. These are strong operational details beyond the schema, though permission or failure-mode behavior is not described.

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 paragraph is front-loaded with the main scrolling model and then layers target selection, return behavior, and post-scroll state. It is dense but efficient for a 14-parameter tool; each clause contributes operational meaning, though the semicolon-heavy structure makes it slightly harder to parse than necessary.

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

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

For a complex, annotation-free tool with no output schema, the description covers the key gaps: how target selection works, what scrolling modes exist, what the tool returns (at-rest notification), how partial movement is reported, and that snapshots must be refreshed after scrolling. It is nearly complete, though it could say more about failure or timeout behavior beyond the schema's timeoutMs.

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 the baseline is 3. The description still adds value by constraining mutually exclusive parameters ('deltaY ... or toY ..., not both'), explaining sign conventions ('positive is down, as scrollTop counts'), and clarifying that emsn -1 applies only when the snapshot offers it. It does not overload schema details but tightens their meaning.

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

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

The description names a specific verb and resource, 'Scroll', and immediately clarifies the two main modes: relative delta scrolling versus absolute to-position scrolling. It is clearly distinguishable from siblings like browser_click or browser_wait because it defines exactly what scrolling means and how the target is selected.

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 explicit selection rules: use deltaY or toY, not both; deltaX/toX are the horizontal equivalents; use emsn for independently scrolling panes; use emsn -1 for the whole page only when the snapshot's page position line offers it. It also states that coordinates become void after a scroll and a fresh snapshot is needed, which is a critical usage constraint.

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 the side effect ('nothing else changes, except that a click giving it focus stays'), the refusal conditions, and the return shape (quoted lines marked ⟦…⟧). It stops short of describing what the selection looks like on the page afterwards or any interaction with subsequent non-toolbar 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?

Front-loaded with the core action and the toolbar follow-up, then the argument rule, then refusals. It is dense with zero filler, though the trailing refusal chain is a long semicolon run that is harder to scan than the lead sentences.

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 10-parameter mutation-free selection tool with no output schema and no annotations, the description supplies what is missing: the return format, the side effect on focus, the argument-selection rule, and a full refusal matrix with remediation. Nothing an agent needs to invoke it correctly is absent.

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%, so the baseline is 3, but the description adds a real constraint absent from the schema: exactly one of select, from+to, or all must be given. It also tells the agent how to derive from/to values ('copy the words from the element's snapshot value as for browser_input_text's before/after'), which the schema does not.

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 (select words in a text field/editable area) and frames the effect precisely: a drag-like selection so a toolbar button acts on it. It differentiates itself from neighbors by referencing browser_input_text (same from/to copying convention) and browser_click (toolbar click in the same batch, picture caption case).

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 states the use case (selection must precede a bold/colour/link click, possibly in the same batch) and gives an alternative route for each refusal: 'select cell by cell' for cross-cell tables, 'click the picture instead' for captioned images. The when-not list is enumerated rather than implied.

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 burden. Beyond the implied activation, it says nothing about whether the containing window is also raised, whether the user's current focus is stolen, or what happens if tabId does not belong to windowId — all material for a state-changing focus operation.

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

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

A single front-loaded sentence with zero filler — the action is stated immediately. It is efficient and readable, though its brevity borders on under-specification rather than tightness.

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 two-required-parameter mutation tool with no annotations and no output schema, the description leaves key behavior unexplained: cross-window validity of the tabId/windowId pair, whether the window is raised, and what is returned on success or failure. The schema documents the inputs, but the agent gets no behavioral envelope.

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%, with both parameters documented ('The tab to bring forward', 'The tab's window'), so the baseline is 3. The description adds no meaning beyond the schema — e.g. whether the pair must be consistent or what failure looks like on mismatch.

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 ('Bring...to the front') and resource ('a tab in its window'), so the action is unambiguous and separable from browser_new_tab/browser_close_tab. It doesn't explicitly contrast with browser_show, which focuses a window rather than a tab, so sibling differentiation is only implicit.

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

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

No guidance on when to call this vs. alternatives such as browser_show (bring window forward) or browser_new_tab. The agent must infer that both windowId and tabId are needed to disambiguate tabs across windows, with no stated preconditions 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?

No annotations are provided, so the description carries the full behavioral burden. It states the basic action but does not disclose side effects, whether the mute state persists, required permissions, or what happens when tabId/windowId are omitted.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though the brevity leaves it under-specified.

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

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

The schema is fully documented and the operation is low-complexity, so the description is minimally sufficient. However, with no annotations and no explanation of behavioral details, it remains adequate rather than complete.

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

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

Schema description coverage is 100%, and the schema already documents muted, tabId, and windowId with defaults. The description adds no parameter meaning beyond the schema, so the baseline score 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 clearly states the specific verb and resource: mute/unmute a tab. It is easy to distinguish from unrelated browser actions such as navigation or clicking, though it does not explicitly contrast with any sibling 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?

The description provides only the core action and no guidance on when to use it, when not to use it, or how it relates to alternatives such as browser_select_tab or browser_get_window_info. Usage is implied by the tool name but not explained.

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 provided, the description carries the full behavioral burden. It usefully explains that windows can be hidden or off screen and that this tool is intended for human viewing, but it does not disclose side effects such as focus changes, stacking behavior, permissions, or failure cases.

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

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

The description is two sentences, front-loads the action, and uses the second sentence to justify the action with a concrete scenario. There is no wasted language.

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 two-parameter UI operation with complete schema coverage and no output schema, the description is largely sufficient. It explains the purpose and human-interaction context, though it could say more about what happens if the window cannot be shown or how focus is affected.

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 parameters are already documented in the schema. The description adds no parameter-specific meaning beyond that, which meets the baseline for high schema coverage.

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 action and resource: bringing a window on screen. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as browser_minimize or browser_get_window_info.

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 a clear usage context: show a window before asking a person to look at it, especially when agent-driven windows are hidden or off screen. It does not name explicit alternatives or exclusions, but the primary when-to-use condition 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?

With no annotations, the description carries the full burden and does it well: it discloses the side effect of raising the window, the blocking behavior (every command on that tab fails except browser_take_snapshot), and the underlying constraint that agent-driven physical input never reaches the page. These are exactly the traits an agent could not 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?

Five short sentences, front-loaded with the action, then the reason, then the consequences and the exit. Every sentence carries information the agent needs; 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?

Zero required parameters, no output schema, no annotations — the description covers purpose, side effects, blocked-command behavior, and how to detect completion and resume. Nothing an agent needs 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 description coverage is 100%, so tabId, windowId, and showWindow are already documented. The description only echoes the window-on-screen behavior tied to showWindow and adds nothing about tab/window targeting, 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 and resource: hand the tab to a person for real keyboard/mouse input. It is clearly distinct from browser_stop_human_control and browser_take_snapshot, both of which are named in context.

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 triggers ('a password, a code sent to them, a captcha, proving who they are') and the reason the agent cannot substitute for them. It also names the exit path (browser_stop_human_control) and the only command that keeps working, so the when/when-not picture is complete.

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 explains that this is a non-acting status check, that first use triggers a multi-minute browser download/install, and that other tools report progress instead of acting until it is ready. It does not describe the exact returned status/progress format, but the important behavioral caveat is 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 description is short and front-loaded with the core purpose, then adds only the necessary first-use installation caveat. There is no redundant or wasted text.

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 status tool with no output schema, the description covers the essential invocation context and the non-obvious first-use installation behavior. It could be slightly more complete by describing the readiness/progress values returned, but it is sufficient for an agent to know when and why to call it.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to compensate for. The schema is empty and fully covered by its structure, making a baseline 4 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: it tells the agent to 'say whether the browser is ready.' It also differentiates this tool from the action-oriented siblings by saying it does so 'without doing anything in it.'

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

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

The description gives clear usage context: it is the tool to call when checking readiness, especially during first-use installation when other browser tools only return progress. It does not explicitly say 'call this before using other tools,' but the intended situation 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?

No annotations are provided, so the description carries the full burden, and it delivers the critical behavioral rule: agent-initiated handovers end freely, while person-initiated ones require consent and can be refused. It stops short of saying what a refusal returns or how the agent should react to it.

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 with zero padding; the core action leads and the conditional consent nuance follows. Every clause carries 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?

For a two-optional-param tool with no output schema, the description covers the action and the consent semantics well. It leaves the failure/refusal path undefined, which an agent calling this in a loop would want to know.

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% with only two optional parameters (tabId, windowId), and the schema already defines their defaults. The description adds nothing about tab or window targeting, so baseline 3 applies.

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

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

The description states a specific verb and object: reclaim a tab from human control and resume automation. This cleanly distinguishes it from the inverse sibling browser_start_human_control, though it never names that sibling explicitly.

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 establishes the context in which the tool applies and splits it into two cases: a handover the agent initiated versus one the person started. It gives no explicit 'do not use when' or named alternative, so it falls 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 disclosure burden. It does add real value by scoping the effect to page loading and disclaiming any impact on running tasks, but it does not say what state the page is left in after the stop, whether it errors when nothing is loading, or whether it is idempotent.

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 sentences with the primary behavior front-loaded, then the scope constraint, then the disambiguation. Nothing is repeated and 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?

For a simple, non-destructive, zero-required-parameter action with a fully documented schema and no output schema, the definition covers what the tool does and how it differs from its nearest sibling. Only minor edge-case behavior (no-op or error when not loading, resulting page state) is left 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 description coverage is 100% and both tabId and windowId are documented in the schema, including their defaulting behavior. The description adds no parameter-level detail 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 ('Stop the page loading in this tab') and anchors it with a concrete analogy to the browser's stop button, so the effect is unambiguous. It also explicitly separates itself from browser_stop_task, which an agent could otherwise confuse with it.

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 exclusion ('This is about page loading only') plus a named alternative and the condition that selects it ('To stop a running browser_run_task, use browser_stop_task'). This is exactly the when/when-not/alternative pattern an agent needs to route correctly among the many browser_* siblings.

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 discloses that the task stops at the end of its current step and does not resume, that closing the tab/window is optional and scoped only to that task's resources, and that other windows are unaffected. It further explains why protocol-level cancellation is insufficient (advisory, may be ignored, cannot tidy the browser).

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 definition is four tightly packed sentences with zero waste. It front-loads the primary action and identifier, then layers optional behavior and disambiguation in a natural order.

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 three-parameter stop tool with no annotations and no output schema, the description provides everything needed: action, identifier provenance, step-boundary behavior, optional cleanup semantics, scope of effect, and sibling differentiation. No material gap remains.

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 the schema already documents taskId, closeTab, and closeBrowserWindow. The description reinforces that taskId comes from browser_run_task and adds that only the relevant tab/window is closed, but it does not add syntax or format details beyond the schema baseline.

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 ('Stop') and resource ('browser_run_task'), including the required identifier source. It explicitly distinguishes itself from browser_stop_loading and protocol-level cancellation, so an agent can select it confidently against siblings.

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

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

It gives explicit when-to-use context and names the precise alternative for a related but different operation: 'To stop a page loading rather than a task, use browser_stop_loading.' It also clarifies that this is not the same as protocol-level cancellation, setting clear boundaries.

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 burden, and it does well: it discloses the emsn numbering contract (act on numbers, not pixels), that PDFs/error pages/crashed tabs are flagged, popup blocking, and staleness semantics. However, it never states the observation is read-only/safe, nor any rate/size limits beyond the readWholePage warning, leaving the agent to infer safety for a browser-inspection 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?

Front-loaded with the core return contract, which is good, but the sentence is a single dense run-on that crams the marks legend, PDF/error/crash handling, multi-tab behavior, and staleness into one paragraph. The marks list ('also dblclick / drag / ...') is valuable but buried and slightly rambling; a short bullet structure would scan far better.

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 and 8 parameters, the description fully explains the return shape (one line per element, position, URL/title, popups, snapshotId), the emsn numbering model, and the special page states. An agent has everything needed to call it and interpret results correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantic value: it explains what snapshotId means and that each tab gets its own, that showLinks produces [^3] footnotes for handing to browser_read_pages, and that readWholePage keeps one screen while marking offscreen lines still emsn-actionable.

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 ('Look at a tab') and enumerates exactly what comes back: one line per element, page position, URL/title, blocking popups, snapshotId. This clearly distinguishes it from browser_read_pages and the action tools (browser_click, browser_input_text), which mutate rather than observe.

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/when-not guidance: take a fresh snapshot after anything that changes the page, give tabIds to look at several tabs in one call, enable showLinks only when addresses are needed, enable readWholePage to search/read a whole page 'not on every look'. It even warns that snapshot marks may under-report listeners ('try it and 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?

With no annotations, the description carries the full burden. It usefully discloses that out-of-range values are clamped rather than rejected (100–10000 ms), which is real behavioral information, but it says nothing about whether the call blocks, what it returns, or how it interacts with concurrent loading.

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 filler, with the purpose front-loaded and the constraint immediately after.

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 single optional parameter with full schema coverage and no output schema means little else is required; purpose and bounds are both stated. Only the blocking semantics remain unstated, a minor gap for a sleep 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?

Schema coverage is 100% and documents the 2000 ms default, so the baseline is 3. The description goes beyond the schema by giving the accepted range and the clamping behavior for the single parameter, which is genuinely additive.

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 ('wait') plus the condition that motivates it ('pages that are still settling'), which separates it from action siblings like browser_reload or browser_stop_loading. It does not name those siblings explicitly, so an agent must infer the boundary itself.

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?

'Wait before looking again, for pages that are still settling' implies when to use it, but there is no statement of when to prefer an alternative (e.g. browser_stop_loading when the load is hung) and no guidance on choosing a duration.

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