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

With no annotations, the description carries the full burden. It does add genuinely useful behavioral detail: the entries are recent command-level records and JS code is stripped from params before being returned (a meaningful data-handling trait an agent should know). It does not cover ordering, retention window, or any auth/permission requirement for reading the audit trail, so it remains partial.

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

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

Two tight sentences with no filler. The return-field enumeration is front-loaded and the use case follows, so nothing needs to be re-read.

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?

Because there is no output schema, the description usefully enumerates the returned fields, which covers the return-value gap. But a query tool with two undocumented filtering parameters and no annotations still leaves the agent guessing about the time-window semantics, which is the one thing needed to call it correctly.

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

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

Schema description coverage is 0% and neither of the two parameters is mentioned in the description. The agent gets no explanation of what limit caps or how since_ms is interpreted (epoch milliseconds vs. relative offset), even though the defaults (100, 0) imply a filtered-window query. The description does not compensate for the coverage gap.

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+resource ("Return recent command audit entries") and enumerates the returned fields, so the agent knows exactly what this produces. It does not explicitly differentiate from nearby siblings like browser_logs or browser_console_logs, which could plausibly be confused with an audit log, so it stops short of a 5.

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

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

"Useful for 'what did the agent do?' reviews" gives an implied use case, which is real guidance. However, it never states when NOT to use it or points to the alternative tools (browser_logs, browser_console_logs) for related diagnostic needs, leaving the selection decision to inference.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does not say what happens when there is no prior history (no-op vs. error), whether navigation waits for the page to load, or how it interacts with the currently active tab. For a history-mutating navigation action this is a notable gap.

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

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

One short sentence that front-loads the action with the clarifying parenthetical, with no filler. It is efficient, though its brevity borders on under-specification rather than true economy.

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 no-output tool the concept is easy to grasp, but with no annotations and an undocumented tab_id the description leaves key call-time questions unanswered (which tab, behavior at the start of history). It is under-described for even a low-complexity navigation 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?

The single parameter tab_id has 0% schema description coverage and no entry in the description, so an agent cannot tell whether null means the active tab, what happens with an invalid id, or whether the operation affects another tab's history. The description adds no meaning beyond the bare property name.

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 (go back) and resource (history), and parenthetically clarifies it mirrors the browser back button, so the action is unambiguous. It does not differentiate from the sibling browser_forward or otherwise acknowledge its place among the navigation tools.

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 vs. browser_forward, browser_navigate, or browser_reload_tab, and no prerequisites or error conditions are mentioned. Usage is only implied by the name and the parenthetical aside.

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 must carry behavior. It discloses the tab targeting behavior and the list of available actions, and notes parallelism limits. However, it does not describe return format, error handling, ordering guarantees, or auth/rate constraints.

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 purpose sentence, followed by structured action list and example. Slightly verbose due to listing every action, but each part is useful. 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?

Given no annotations and no output schema, the description covers the core invocation pattern and action enumeration, which is the most important missing schema information. It still omits return values, error semantics, and detailed parameter contracts for individual actions.

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

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

Schema coverage is 0% and the schema only says commands is an array of objects. The description compensates substantially by explaining the command dict shape (action + parameters) and giving an example, plus the tabId convention. This is better than 0% coverage but not exhaustive for all action parameters.

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

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

The description states a specific verb (run multiple commands), resource (commands in a single request), and benefit (for speed). It clearly distinguishes itself from the many single-action siblings by being the batch runner.

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 provides clear context: use for speed and targeting specific tabs via tabId. It explicitly points to browser_parallel for true concurrency. It does not state exclusions or when not to use batching beyond that, but the routing to an alternative is strong.

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. It does disclose the useful default (falls back to document.activeElement), but says nothing about whether blur events are dispatched, what happens if the selector matches nothing, whether a tab_id is required, or what the result 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?

A single tight sentence, front-loaded with the action and immediately qualifying the default target. Nothing is wasted, though the extreme brevity leaves the definition under-specified rather than merely concise.

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-parameter tool with zero schema description coverage, no annotations, and no output schema, the description leaves key gaps: tab_id semantics are undocumented and no return or error behavior is described. The active-element default is the only real completeness win.

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

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

Schema description coverage is 0%, so the description must compensate. It explains selector semantics well, including the default when omitted, but leaves tab_id completely unexplained, so only one of two parameters gains meaning from the description.

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

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

States a specific verb ('blur') and resource ('an element'), and adds the default target (document.activeElement) when no selector is given. The sibling browser_focus is the natural counterpart, but the description never names it or draws the contrast, so differentiation is left 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?

There is no when-to-use guidance: no mention of when blurring is appropriate versus focus-related siblings like browser_focus, and no prerequisites or context. The only guidance is the implicit 'omit selector to blur the active element.'

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 it does disclose the return content (bounding rect + viewport/page sizes), which is valuable since no output schema exists. However it omits whether the element is scrolled into view, how it handles a missing element, or whether it waits, so it is only moderately transparent.

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 no filler, and the key content (return value) comes first. It is efficient, though its brevity is partly a byproduct of under-specification rather than deliberate economy.

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 annotations, no output schema, and 0% parameter description coverage, the description is the only guidance available and it is thin. It should at minimum clarify the selector parameter, tab_id behavior, and error/wait behavior for an element-measurement 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 description coverage is 0%, so the description must compensate for two undocumented parameters. It never mentions `selector` or `tab_id`; "for an element" only loosely implies a selector and gives no format, syntax, or tab-scoping semantics. The schema-completion burden is left unmet.

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 ("Return") and specific content (getBoundingClientRect plus viewport/page sizes for an element), so an agent knows exactly what it computes. It does not distinguish itself from nearby siblings like browser_computed_style, browser_full_page_metrics, or browser_element_screenshot, so it falls short of a 5.

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

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

There is no explicit when-to-use guidance and no named alternative. The agent must infer that this is the tool for measuring an element's position/size versus, say, browser_computed_style or browser_full_page_metrics. No exclusions or contextual routing are given.

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 must carry the full behavioral burden, and it does disclose useful traits: parallel execution, automatic per-tab tabId injection, per-tab results keyed by tab id, and that timeout is per-tab. It says nothing about partial failure handling, concurrency limits, or whether mutating commands are safe to broadcast, so the safety profile remains unspecified.

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 sections, front-loaded with the core behavior before the argument list. Every sentence earns its place, and the arg notes are justified by the 0% schema coverage rather than redundancy.

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

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

For a tool with a nested free-form command object, no output schema, and no annotations, the description covers the essentials: what runs in parallel, how tabId is injected, and the shape of the result. The remaining hole is failure/partial-success semantics, which for a broadcast tool is the one thing an agent would most 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 0%, so the description has to compensate, and it largely does: tab_ids are identified as the target tabs, timeout as per-tab seconds, and the free-form command object is illustrated with concrete examples ({"action": "pageInfo"}). This adds meaning the schema cannot, since command is an untyped object with additionalProperties and no examples of its own.

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: fire the same command at every listed tab in parallel. An agent can tell generally what it does, but the description never distinguishes it from overlapping siblings like browser_parallel or browser_batch, so the routing decision is left ambiguous.

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 purpose sentence: use it when you want the same command applied across many tabs. There is no explicit when-not guidance and no mention of the closest alternatives (browser_parallel, browser_batch), which is a real gap in a sibling set this dense.

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?

There are no annotations, so the description carries the full behavioral burden for a state-mutating tool. It does not state what cache scope is affected (tab, session, bridge), whether 'clear' is destructive or reversible, what 'status' returns, or what effect setting a TTL has. Only the parameter surface 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?

Two short lines of prose plus an Args block, with the purpose front-loaded before the parameter notes. Slightly arg-block heavy, but no wasted 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 mutation-capable cache tool with no annotations, no output schema, and 0% schema coverage, the description should cover side effects, scope, and result shape. None of that is present, leaving an agent unable to predict the consequences of 'clear' or 'ttl'.

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

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

Schema description coverage is 0%, so the description must compensate, and it partly does: it documents the three valid action values and clarifies that seconds only applies when action is 'ttl'. However, it omits the default of 'clear' and the accepted range/units for seconds, leaving gaps.

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 (Control) and a specific resource (Kitsune bridge response cache), and enumerates the three action values. That is enough to distinguish it from the dozens of siblings like browser_clear_browsing_data or browser_status, though it does not name an alternative 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 lists the action values but never says when to reach for this tool versus siblings such as browser_clear_browsing_data, browser_reload_extension, or browser_storage, nor any prerequisites. Usage must be inferred entirely from the parameter names.

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 meaningful behavior: capture is buffered, 'start' resets fresh, 'stop' merely pauses, and everything runs through the page's PerformanceObserver. It omits important traits such as buffer size limits, whether the buffer survives navigation, and what entry fields are returned.

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

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

The purpose sentence is front-loaded and the Args block is well structured with one line per parameter. It is tight overall, though the Args list format is somewhat mechanical rather than prose-optimized.

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 tool with no output schema and no annotations, the description covers the operation modes, filtering, and tab targeting adequately. It stops short of describing the shape of the returned buffer entries, which the agent would need to consume the 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 description coverage is 0%, so the description must fully compensate, and it does: all three parameters are explained, including every op value, the millisecond semantics of 'since' ('startTime >= since'), and that tab_id is optional and defaults to the active tab.

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 ('Capture network requests') and names the underlying mechanism (PerformanceObserver), so the agent knows exactly what is being observed. It does not, however, distinguish itself from nearby siblings like browser_intercept or browser_wait_for_network_idle, leaving overlap for the agent to resolve.

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 op modes ('start' captures fresh, 'stop' pauses, 'read' returns the buffer) implicitly tell the agent how to drive the tool, and 'read' being the default is helpful. There is no explicit guidance on when to prefer this over browser_intercept or browser_wait_for_network_idle, so usage versus alternatives is only 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?

With no annotations, the description carries the full behavioral burden for a mutation tool, yet it discloses nothing beyond the action itself: no scroll-into-view, event dispatch, error-on-missing-element, or idempotency behavior, and no return info. The only implicit hint is that a boolean 'checked' can both check and uncheck.

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 no wasted words. It is efficient, though brevity here tips into under-specification rather than crisp conciseness.

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

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

For a 3-param mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. Key details like tab targeting, selector syntax, and failure behavior are 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 description coverage is 0%, so the description must compensate, but it only loosely maps to 'checked'. Neither 'selector' (format expected) nor 'tab_id' (which tab is targeted) is explained anywhere.

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 'Set' plus a precise resource ('checkbox or radio's checked state') makes the action unambiguous and separates it from browser_click/browser_fill in concept. It stops short of naming alternatives or noting that it targets form controls specifically, so it isn't fully sibling-differentiating.

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 when-to-use guidance, no mention of alternatives such as browser_click, browser_select_option, or browser_fill, and no prerequisites (e.g., that the element must be a checkbox/radio). The agent is left to infer usage entirely.

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 usefully discloses the destructive scope by enumerating exactly what can be wiped (cache, cookies, history, localStorage, passwords, downloads) and the since_ms time filter. However, it never states that the action is irreversible, whether it affects other open tabs/sessions, or what permissions are needed.

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 in the first sentence, then concise per-parameter notes. The docstring-style 'Args:' formatting is slightly mechanical but wastes no words and stays small.

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, no-annotation, no-output-schema tool, the description covers inputs well but leaves notable gaps: it does not warn about permanence, cross-tab scope, or return value. An agent has enough to call it, but not enough to call it safely.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it enumerates the valid type values, states the default (all), and explains since_ms as an epoch-ms lower bound. This adds real meaning beyond the bare 'Types'/'Since Ms' schema titles, though it omits whether types accepts a single string vs array.

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?

Clear specific verb+resource: 'Clear browsing data of the given types.' An agent immediately understands the operation. It does not differentiate from near-siblings like browser_cache, browser_cookies, or browser_storage, which conceptually overlap with the clearable types enumerated here.

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

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

The description implies when the tool applies (clearing browsing data) and notes that types defaults to all, but offers no guidance on alternatives such as browser_cache or browser_cookies for narrower operations, and no when-not-to-use or prerequisite conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no mention of what happens on a missing element, whether the click blocks/waits, whether it triggers navigation, or what is returned. For a mutating, state-changing browser action this is a substantial gap.

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?

Short and front-loaded: the core action is the first sentence, followed by a compact Args block. The Args list partially duplicates the schema but does add the priority semantics, so it largely 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?

With no annotations and no output schema, the description must cover behavior and results, and it does not — nothing about success/failure signaling, error conditions, or waiting semantics. An agent can form the call but cannot predict its side effects or failure modes.

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

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

Schema coverage is 0%, yet the description documents all four parameters, explains the selector priority rule (x/y used when selector is empty) and the default tab behavior. That meaningfully compensates for the undocumented schema, though it omits any selector syntax limitations or coordinate reference frame (viewport vs page).

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 (element on the page) plus the two targeting modes (CSS selector or coordinates). It is clear what the tool does, but it never differentiates itself from close siblings like browser_trusted_click, browser_double_click, or browser_click_and_wait_navigation.

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 choose this over browser_trusted_click (which likely exists for a reason, e.g. bypassing event-trust checks) or browser_click_and_wait_navigation. The only conditional logic given ('used if selector is empty') is parameter mechanics rather than tool-selection guidance.

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

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

With no annotations, the description carries the full burden and does add real mechanism detail — it listens for tabs.onUpdated(status='complete'), which tells the agent exactly what completion means. However it omits error/timeout behavior (what happens if navigation never completes within the 15s default) and any side-effect or permission notes for what is effectively a click/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?

Front-loaded with the core action, followed by the differentiation note and then the mechanism. Three tight sentences with little waste, though the mechanism detail is slightly technical relative to the routing value.

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

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

No annotations, no output schema, and 0% parameter coverage mean the description should carry more than it does. Purpose and completion semantics are well covered, but the failure mode on timeout and the meaning of the three parameters are left entirely unexplained, leaving real gaps for a callable mutation 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 description coverage is 0% across 3 parameters, so the description must compensate and does not: `selector`, `tab_id`, and `timeout` are never mentioned or explained. The only indirect relevance is that the wait mechanism implies what `timeout` governs, but no syntax, format, or default semantics are added.

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 compound action — click an element, then wait for navigation — with a clear verb and resource. It explicitly distinguishes itself from siblings by naming `browser_click` + `browser_wait_for_url` and declaring itself the more reliable atomic alternative for links/submit buttons.

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?

Clearly signals when to use it (links/submit buttons that trigger navigation) and names the alternative sequential tools it replaces, which is strong routing guidance. It stops short of stating when NOT to use it, e.g. for clicks that do not navigate, where plain `browser_click` would be correct.

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, but it says nothing about whether write overwrites existing clipboard content, whether read requires focus/permissions, or what errors can occur. For a system-level side-effecting tool this is a notable gap.

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?

Very short and front-loaded, with the operation summary in the first sentence and parameter detail following. The Args block is slightly redundant with the schema but earns its place by supplying the op values.

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 tool with no output schema, the description is largely sufficient, but it omits what read returns, the effect of write on existing clipboard data, and error conditions. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines op as "read" or "write" (adding the enum the schema lacks) and explains that text is only used when op="write". Minor gaps remain around the read return format, but the core semantics are covered.

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

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

States a specific verb pair (read/write) and a concrete resource (system clipboard), so the tool's function is unambiguous. It does not explicitly differentiate itself from siblings, but the clipboard resource is unique enough that confusion is unlikely.

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 use clipboard operations versus alternatives, nor prerequisites such as focus or permissions. The description only restates the two operation modes implied by the parameters.

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. It discloses a genuinely useful quirk — that upload/editor pages hold a tab open via beforeunload and cause the close to time out unless force is set — but says nothing about behavior on a missing tab ID, errors, or loss of tab/session 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 core action is front-loaded in a single sentence, followed by a compact per-argument breakdown. The Args block is slightly verbose but every line carries information about behavior or value source.

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 close tool with no output schema and no annotations, the description covers purpose, both parameters, and the key timeout quirk. Only explicit error/return behavior is absent, a minor gap for such a simple operation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: tab_id is annotated with its source (browser_tabs), and force is explained with its mechanism and the failure mode it prevents. This adds real meaning beyond the bare integer/boolean schema types.

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

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

The description states a specific verb (close), resource (browser tab), and selector (by its ID). It is clearly distinguishable from the sibling browser_close_window since it explicitly scopes to a tab, not a window.

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 useful route guidance by pointing to browser_tabs as the source of tab IDs, and explains the force condition. However, it never states when to prefer this over close_window or other tab-management siblings, leaving the when-to-use decision largely 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 of behavioral disclosure. It does not state that this is destructive, what happens to the tabs inside the window, whether the window's state is lost, or how failures (e.g. invalid/last window ID) are surfaced.

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 short sentence with the action and the required input front-loaded and no wasted words. It is efficient, though it is terse enough that the source-of-ID hint is the only added content.

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

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

For a one-parameter destructive tool with no annotations and no output schema, the description covers the mechanics but omits consequence information (tabs closed, state lost) and error behavior. Adequate minimum, but not complete for a mutation operation.

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

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

The single window_id parameter has 0% schema description coverage, so the description must compensate. It does supply the one genuinely useful fact — that the ID comes from browser_windows — but adds no type, validity, or error semantics beyond that.

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

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

States a specific verb ('Close') and resource ('a browser window') plus the identifier it operates on, which is enough to separate it from browser_close_tab at a glance. It stops short of explicitly contrasting itself with its very similar siblings (browser_close_tab, browser_focus_window, browser_windows), so it is clear but not fully differentiated.

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 parenthetical '(from browser_windows)' implies the workflow: obtain the window_id from browser_windows, then close it here. That is useful inferred guidance, but there is no statement of when to close a window versus a tab, nor any prerequisites or warnings.

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. It states the default property set but omits whether this is read-only, what tab state or permissions are required, what the return shape looks like, and how tab_id defaults when 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?

Two tight sentences, front-loaded with the action and followed by the default behavior. 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 3-parameter tool with no annotations and no output schema, the description is too sparse to ensure correct invocation. It omits tab_id behavior, properties syntax, return structure, and error conditions.

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

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

Schema description coverage is 0%, so the description must explain all three parameters. It implicitly covers selector ('for an element') and properties default ('layout-relevant set'), but tab_id is never mentioned, leaving a key parameter undocumented.

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

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

States a specific verb ('Return') and resource ('computed CSS for an element'), distinguishing it from DOM/HTML inspection siblings. It does not explicitly say how it differs from browser_dom or browser_explain_selector, so it stops short of a 5.

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

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

No when-to-use guidance, no alternatives named, and no prerequisites such as needing an attached tab. The only usage hint is the default property set, which is behavioral rather than selection 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 behavioral burden. It usefully discloses that logs are buffered (implying capture rather than live streaming) and names a hard dependency, but says nothing about whether the buffer is drained or retained after retrieval, result limits, or ordering. Enough to be viable, not enough to be rich.

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 naming the action, the resource, and the key precondition. 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?

With no annotations, no output schema, and 0% parameter coverage, the description needs to do more heavy lifting than it does. The core purpose and one hard prerequisite are covered, but filtering semantics (level, since) and return behavior are left entirely for the agent to guess.

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

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

Schema description coverage is 0% across three parameters (level, since, tab_id) with no enums. The description only loosely implies tab_id via 'from a tab' and says nothing about what 'level' accepts (log level names?) or what 'since' measures (timestamp, index, sequence number). With zero schema-side documentation, the description should compensate and 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: 'Return buffered console logs from a tab.' The mention of the buffered nature and the tab scope distinguishes it from the sibling browser_watch_console, which is referenced as a prerequisite. It is less clear against browser_logs, but the 'console' qualifier does meaningful work.

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 precondition: 'requires browser_watch_console first.' This tells the agent when the tool is callable and implicitly routes it to the sibling that must run beforehand. No exclusions or alternative-selection guidance are offered, so it stops short 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 behavioral burden. It usefully discloses that clear wipes all cookies for a url/domain (a destructive effect), but says nothing about whether set overwrites existing cookies, whether operations persist across sessions, permission/auth needs, or what get 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?

The front-loaded summary followed by a tight per-operation bullet list is easy to scan and wastes no words. Slightly more explanation of the two undocumented parameters would have earned a 5.

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 7-parameter, mutation-capable tool with no annotations, no output schema, and 0% schema coverage, the description is adequate but incomplete: it omits path/secure semantics, error behavior, and any return-value expectations for get.

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

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

Schema coverage is 0%, so the description must compensate. It documents op, url, name, value, and domain, and states the required combinations per operation. But it leaves path and secure entirely unexplained (including secure's default of false), so two of seven parameters remain undocumented.

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

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

The description names the resource (cookies) and enumerates the four supported operations, so an agent can tell what the tool does without opening the schema. It does not explicitly differentiate itself from near-siblings like browser_storage or browser_clear_browsing_data, but the operation set is specific enough to be 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?

Per-operation requirements (set needs url+name+value, remove needs url+name, get uses url/domain/name to filter) give implied usage context. However, there is no guidance on when to use this over browser_storage or browser_clear_browsing_data, and no mention of prerequisites or 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?

No annotations are provided, so the description carries the full burden. It says nothing about whether the new window becomes focused/active, how the incognito flag changes behavior or isolation, or whether the created window persists across other tool calls — all material for a window-creation 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 short sentences, front-loaded with the core action and with zero filler. It is efficient, though the terseness is partly the source of the missing detail penalized in other dimensions.

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 creation tool with no annotations, no output schema, and siblings such as browser_close_window, browser_focus_window, and browser_windows that presumably operate on a window identifier, the description never indicates what the call returns or how the new window is referenced later. That gap leaves the agent unable to chain calls correctly.

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

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

Schema description coverage is 0% for both parameters. The description explains 'url' adequately ('pass a URL to load it at start'), but says nothing at all about the 'incognito' boolean, which is exactly the kind of flag an agent needs explained. Half the parameters remain undocumented in both schema and description.

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

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

States a specific verb and resource: 'Open a new browser window,' which is clearly distinct from the tab-oriented siblings in name. However, it never explicitly contrasts itself with browser_new_tab or browser_navigate, so the agent must infer the window-vs-tab distinction from the name 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?

The only guidance is 'Pass a URL to load it at start,' which is parameter advice rather than usage guidance. There is no indication of when to create a new window versus a new tab (browser_new_tab), when to navigate an existing window (browser_navigate), or any prerequisite/ordering 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that the operation is irreversible, what happens if the named session does not exist, whether it requires the session to be inactive, or whether anything is returned. 'Delete' implies mutation, but that is all the agent gets.

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 waste. It is concise, but the brevity reflects under-specification rather than high information density.

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 tool with no annotations, no output schema, and an undocumented required parameter, the description is well short of what an agent needs. It should at minimum flag irreversibility and the relationship to the session save/load/list tools.

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

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

Schema description coverage is 0% and the single parameter 'name' is completely undocumented in both schema and description. The description never says whether 'name' is a session identifier, a filename, or a friendly label, nor what format it takes.

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 ('Delete a saved session file'), so an agent can tell what the tool does. However, it never distinguishes itself from its obvious siblings browser_save_session, browser_load_session, and browser_list_sessions, so the differentiation that would earn a 5 is absent.

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 when-to-use guidance, no mention of prerequisites (e.g. the session must exist, must not be the active session), and no pointer to save/load/list alternatives. The agent must infer the entire usage context from the name alone.

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 implies a structural mutation of window/tab state, yet says nothing about what happens to the source window (does it stay open or close if it becomes empty), whether the tab keeps its identity/state, or what the return 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?

A single, front-loaded sentence with no filler and no ambiguity in phrasing. It is efficient, though extremely terse given the disclosure gaps elsewhere.

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 mutating tool with no annotations, no output schema, and 0% parameter documentation, this one-liner is insufficient. It should at minimum describe the required tab_id and the effect on the originating window.

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

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

Schema description coverage is 0%, and the description never mentions the single required parameter (tab_id) or its expected format or origin. The phrase 'a tab' only weakly implies an identifier is needed, so it fails to compensate for the undocumented schema.

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

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

The description states a specific verb ('pop out') and resource ('a tab') and states the outcome ('its own new window'), which differentiates it from a plain move into an existing window. It could explicitly name browser_move_tab or browser_duplicate_tab as the alternatives, but the action and result are unambiguous.

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

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

There is no guidance on when to detach versus move, duplicate, or create a new window, and no prerequisites or exclusions are given. The agent must infer the use case from the name alone.

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 discloses the read-only nature implicitly via 'Get', but does not state whether it waits for elements to load, whether it scrolls, or what happens with no interactive elements present. It provides the tab_id default behavior, which is helpful but minimal.

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 brief and front-loaded with the primary purpose. The Args section is somewhat redundant given the single parameter, but not wasteful. It could be slightly more structured.

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 read-only DOM inspection tool with no output schema and no annotations, the description is minimally adequate but lacks details about return format, pagination, or handling of non-interactive elements. The complexity is moderate (accessibility tree), so more context would be beneficial.

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

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

Schema coverage is 0%, so the description must compensate. It does explain that tab_id is optional and defaults to the active tab, which adds value beyond the schema's bare 'anyOf' type. However, with only one parameter, the baseline is 4 for zero params, but here one param is undocumented in schema and only partially explained.

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 (Get) and resource (accessibility tree of interactive elements) clearly. However, it does not distinguish itself from closely related siblings like browser_find, browser_click, or browser_forms, which an agent might confuse when seeking element information.

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 guidance on when to use this tool versus alternatives. The description implies a read of DOM structure, but with dozens of sibling tools for querying the DOM (browser_query, browser_html, browser_find), the lack of routing guidance is a notable gap.

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 'synthetic' is the one useful disclosure (contrasting with browser_trusted_click's trusted events). It says nothing about failure behavior when no element matches, visibility/actionability requirements, waiting semantics, or what the tab_id targeting implies.

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. It is efficient, though its brevity comes at the cost of the omissions noted elsewhere rather than being a model of dense 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 an input-action tool with no annotations, no output schema, and 0% parameter documentation, one sentence is not enough. It omits selector format, tab targeting, error behavior, and any differentiation from the click siblings.

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

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

Schema description coverage is 0% for two parameters. 'Matched element' weakly implies the selector's role, but selector syntax is never explained and tab_id (null default, active tab presumably) is completely unaddressed in the description.

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

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

Names a specific verb (double-click) and resource (matched element), clearly distinct from browser_click's single-click semantics. However, it never explicitly names or differentiates itself from its closest siblings, browser_click and browser_trusted_click, leaving the agent to infer the 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 guidance on when to use this versus browser_click, browser_trusted_click, or browser_hover, and no prerequisites stated. The agent must infer usage entirely from the tool name.

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 and no output schema, so the description carries the full burden and delivers little: it does not say where files land, whether downloads persist across sessions, whether 'list' returns only the current session's entries, or what happens to partial files on cancel. There is also no mention of permissions or rate limits.

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?

Very terse and front-loaded, with a compact arg list that is easy to scan. The redundant header 'Downloads operations' wastes one line, but nothing else is 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?

Four parameters at 0% schema coverage with no annotations and no output schema leaves the definition too thin: an agent cannot tell how to identify a download to cancel, what 'list' returns, or where downloaded content is written. The op-to-param mapping is the only real substance.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially by binding url/filename to 'download' and query to 'list'. However, 'cancel' has no documented identifier parameter even though cancelling a transfer clearly requires one, and no accepted query keys or filename constraints are given.

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 header 'Downloads operations' is vague, but the op enum (download, list, cancel) makes the resource and the three concrete actions recoverable. No sibling tool covers downloads, so differentiation is not the issue here; the gap is that the tool's core behavior (fetching to disk? tracking in-progress transfers?) is only implied.

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

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

The description maps parameters to operations but never states when to reach for this tool, whether 'download' blocks until completion, or how 'cancel' selects its target. Usage must be inferred entirely from the op names.

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. It usefully identifies synthetic HTML5 drag events but omits crucial behavior: side effects, whether it waits for drop handlers, error behavior on missing selectors, and whether the drag is trusted. This is below minimum viable for an unannotated interaction 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?

A single sentence, front-loaded with the core action and resource, with no wasted wording. It is appropriately sized for the core purpose even though additional detail is needed elsewhere.

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 browser interaction tool with no annotations and no output schema, the definition is too thin. It lacks parameter usage, behavioral caveats, and routing guidance among the many sibling browser tools, leaving an agent under-informed.

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

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

Schema description coverage is 0%, so the description must compensate. 'From one element to another' loosely maps to from_selector and to_selector, but tab_id is never mentioned and no selector syntax or constraints are given. Partial compensation leaves a significant gap.

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 (drag-and-drop) and resource (one element to another) and specifies the mechanism (synthetic HTML5 drag events). It does not explicitly differentiate itself from sibling interaction tools such as browser_click or browser_trusted_click, but the 'synthetic' qualifier is meaningful.

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?

Provides no when-to-use guidance, no alternatives, and no exclusions. An agent cannot tell from the description whether to prefer this over browser_click, browser_hover, or any trusted-event variant, nor when drag-and-drop is inappropriate.

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 omits whether the duplicate preserves URL, history, or state, whether focus switches to the new tab, and whether the operation requires an existing tab at all.

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, front-loaded sentences with no filler; the return-value note is efficient. It is under-specified rather than bloated, so conciseness itself is fine.

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 annotations and no output schema, the description had room to cover the missing semantics and did not. The return format is adequately covered by the second sentence, but target-tab selection and side effects remain unexplained.

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

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

Schema coverage is 0% and the single parameter tab_id is optional with default null. The description never explains what tab_id means or what the null default does (presumably the active tab), which is the one piece of information an agent most needs.

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 (duplicate) and resource (tab), and the return value is noted. It is distinguishable from browser_new_tab and browser_move_tab by implication, but it never says which tab is duplicated (active vs. specified), leaving a real ambiguity.

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 such as browser_new_tab or browser_move_tab, even though the sibling list contains several closely related tab-creation tools. The agent must guess which to pick.

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 well: it discloses the scroll-into-view + OffscreenCanvas crop mechanics, that a PNG file is persisted, and that the return value is the saved path. This is meaningful behavioral context. It omits failure modes (e.g., element not found) and any permission/setup expectations, keeping it short of a 5.

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

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

Front-loaded with a one-line purpose, then a compact mechanical note, then a tidy Args list. The list format is justified given the 0% schema coverage, though a couple of lines (e.g., the scale explanation) run slightly long.

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 annotations and no output schema, the description covers the return value (saved_to path plus optional data_url) and the operational behavior. It is largely sufficient for correct invocation, missing only error/edge-case behavior and prerequisites.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does: every one of the five parameters is documented with semantics and defaults (selector meaning, tab_id default-to-active, default save path, data_url size warning, scale meaning and extension-version requirement). This adds substantial value the bare schema cannot convey.

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 ('Screenshot') and a precisely scoped resource ('a single element'), which implicitly separates it from browser_screenshot and browser_full_page_screenshot. An agent can distinguish the element-level scope without opening any schema.

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

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

No explicit when-to-use-this-vs-alternative statement; the element-scoping is implied rather than contrasted with the sibling screenshot tools. The only guidance present is parameter-level ('data_url: only if you really need the bytes inline'), which is useful but doesn't tell the agent when to pick this tool over the full-page variants.

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

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

No annotations, so the description carries the full burden. 'Diagnose' implies a non-mutating read, and it usefully describes the return content (count, samples, suggestions), but it omits any statement about permissions, tab targeting behavior, or whether it triggers page interaction.

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 a clean verb–resource–payload structure; nothing redundant. It could be slightly more informative without losing tightness, but it wastes no words.

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

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

With no output schema, the description is the only source of return-value context and it partially delivers (count, samples, suggestions). However, the tab_id parameter and any scoping behavior are left unexplained, leaving a gap for a tool that must be selected and invoked 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 0% for two parameters. The description mentions 'selector' implicitly via its subject but never explains the format or the role of the undocumented tab_id, so it fails to compensate for the coverage gap.

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 (diagnose) plus resource (CSS selector) and even previews the returned payload (match count, sample matches, suggestions). This distinguishes it from query tools like browser_find or browser_query, though it doesn't name any 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?

The phrase 'if you got too many' implies the diagnostic context (selector matched more than expected), but no alternatives are named and there is no explicit when-to-use vs when-to-pick-something-else 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 full behavioral burden. It notes the direct-set approach and the active-tab default, but omits the critical trait of direct value assignment: whether input/change events fire, whether it works on select/checkbox elements, and whether prior values are overwritten. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

The purpose is front-loaded in one sentence and the args list is compact, with the speed differentiator given prominence. The args list largely duplicates the schema property names but is justified given 0% schema coverage.

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 mutation tool with no annotations and no output schema should disclose event semantics, failure behavior (e.g., selector not found), and result shape. None of that is present; the definition is adequate only for a rough invocation.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It does document all three parameters and adds slightly useful detail ("CSS selector of the input/select element", tab_id optional with active-tab default), but "value: Value to set" is pure restatement and no formats or examples are given.

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 ("Set a form field's value") and adds a differentiating clause ("faster than typing") that separates it from the sibling browser_type. It does not, however, distinguish itself from browser_form_fill or browser_set_editable_content, which also mutate field content.

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?

"Faster than typing" implies the selection rule against browser_type, so usage is inferable. There is no explicit when-to-use vs when-not-to-use, no mention of browser_form_fill (multi-field filling) or browser_select_option (dropdowns), so the agent must guess which form mutation tool applies.

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 mentions that tab_id defaults to the active tab, but does not disclose whether the operation is read-only, what it returns, how missing elements are handled, or whether it waits for elements. Behavioral context is largely absent.

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

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

Front-loads the core action in one sentence, then uses a compact Args section for parameters. Every line 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 find tool with no output schema, the description should explain what the tool returns (e.g., element handles, selectors, coordinates) and how to use the result. It omits return behavior, error conditions, and usage context, leaving significant gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining the query parameter with examples and clarifying that tab_id is optional and defaults to the active tab, adding meaningful detail beyond the bare schema.

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

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

States a specific verb (Find), resource (elements on the page), and method (natural language description), making the core action clear. It does not differentiate from sibling tools like browser_query or browser_dom, so it falls short of a 5.

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

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

Provides no when-to-use guidance, no alternatives, and no prerequisites. The agent must infer that this tool is for locating elements before acting on them, which is not 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?

No annotations and no output schema, so the description carries the full behavioral burden, yet it discloses almost nothing: no error behavior when the selector does not match, no waiting/scrolling behavior, no note on whether tab_id defaults to the active tab, and no side effects (e.g. whether focus triggers blur events on the previously focused element).

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 no padding, which is good. But at this length it reads as under-specification rather than genuine conciseness — nothing was trimmed because nothing was ever added.

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, 2-parameter browser mutation tool, the description leaves out error handling, targeting scope, tab selection, and interaction with related tools like browser_blur and browser_click. An agent cannot call this confidently in edge cases.

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

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

Schema description coverage is 0%, so the description must compensate and it does not: 'selector' is only implied by the phrase 'the matched element' with no syntax or matching rules, and the optional 'tab_id' parameter is never mentioned at all or explained as a default-to-active-tab behavior.

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

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

States a specific verb ('move focus') and a specific target ('the matched element'), so an agent can tell it apart from browser_blur, which does the opposite. It does not, however, differentiate itself from other element-targeting siblings by noting what 'matched' means (a CSS/XPath selector resolved at call time).

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 use this versus browser_blur, browser_click (which also focuses), or browser_highlight. No prerequisites such as requiring the tab to be active or the element to exist. The agent must infer all of this from the name.

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. It does not say whether this is an OS-level focus change, what happens if window_id is invalid or already focused, whether it can fail, or any side effects on other windows.

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 a single front-loaded sentence with no filler, which is structurally sound, but the extreme brevity here is under-specification rather than effective conciseness given the undocumented parameter and absent annotations.

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

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

With no annotations, no output schema, and an undocumented required parameter, the definition leaves the agent without enough information to call it confidently or handle failure cases. A sentence on window_id provenance and error behavior would close the gap.

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

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

Schema description coverage is 0% and window_id has no documented meaning, source, or format. The description mentions 'a browser window' but never explains how to obtain a valid window_id (e.g., from browser_windows), so it fails to compensate for the coverage gap.

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 gives a specific verb ('bring ... to the foreground') and a specific resource ('a browser window'), so the basic action is unambiguous. It does not, however, differentiate itself from nearby siblings such as browser_focus, browser_switch_tab, or browser_windows, which is the main missing signal.

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 rather than browser_focus, browser_switch_tab, or browser_windows, and no mention of preconditions such as the window needing to exist. The agent must infer usage from the name alone.

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 full burden and does disclose the fuzzy-matching precedence and which setter is used per element type, plus that results are returned per-key. It omits important behavioral traits: whether input/change/blur events fire, what happens to keys that match nothing, and any permission or page-state prerequisites.

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

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

The core behavior is front-loaded in the first sentence, followed by resolution and setter rules and a compact example. Every sentence contributes; the repeated 'Args:' label is mild overhead but the example it introduces adds value.

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

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

For a nested, free-form-object tool with zero schema coverage and no output schema, the description covers the required `fields` semantics and notes the return shape. However it leaves `tab_id` unexplained and gives no failure/event semantics, so an agent must still guess on tab targeting.

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

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

Schema coverage is 0%, so this is where the description earns its keep: it fully explains the free-form `fields` object, including the key-resolution chain (CSS selector → name → label → placeholder) and value handling per element type, with a concrete example. The second parameter, `tab_id`, is never mentioned in either schema or description, leaving one gap.

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 ('Fill many fields at once') with a clear scope modifier ('many') that implicitly distinguishes it from the single-field browser_fill sibling. It does not name the alternative tool, so differentiation still requires the agent to infer from 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?

Usage is only implied: the batch framing suggests using this instead of browser_fill when filling multiple fields, but there is no explicit when-to-use, when-not-to-use, or named alternative. No guidance on prerequisites such as needing the form loaded or a specific 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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description says nothing about whether it penetrates iframes/shadow DOM, how it handles hidden or disabled fields, pagination or size limits, or whether it touches the active tab only. The single 'Defaults to active tab' note is the only behavioral detail offered.

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 segments, front-loaded with the core purpose before the args block. Nothing is padded, though the 'Args:' stanza is the minimum needed rather than elegantly integrated.

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

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

For a single-optional-parameter read tool with no output schema and no annotations, the description is minimally viable: it says what it returns at a high level and clarifies the tab parameter. It omits return shape and edge-case handling, but with no output schema the agent still lacks the exact structure it will receive.

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

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

Schema description coverage is 0%, so the description must compensate. It does: 'tab_id: Optional tab to target. Defaults to active tab' explains both optionality and the effective default, which the raw schema (nullable integer, default null) does not convey. Only one parameter exists, so this is close to fully covered.

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: 'Get all form fields on the current page with their labels and values.' This distinguishes it from generic page readers like browser_dom or browser_html by scoping it to form fields with labels and values. It does not, however, explicitly name a sibling it replaces, so it stops short of a 5.

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

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

There is no guidance on when to use this rather than browser_dom, browser_find, browser_page_text, or the form-mutating siblings (browser_form_fill, browser_fill). The only usage context implied is 'current page,' which comes from the purpose statement rather than any explicit directive.

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 supplied, so the description must carry the full behavioral burden. It does not disclose whether the navigation waits for page load, what happens if there is no forward history, what permissions are needed, or what the tool 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?

The description is a single short sentence and is front-loaded with the core action. It contains no wasted words, though it is so terse that it lacks any supporting structure.

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 browser navigation tool with an undocumented optional parameter, no annotations, and no output schema, the description is incomplete. It does not explain parameter semantics, side effects, or error conditions, leaving important gaps for an agent.

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 schema has one optional parameter, tab_id, with 0% description coverage. The description does not mention tab_id at all, so an agent receives no guidance on what the parameter does or when to supply it.

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

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

The description states a specific browser action with a clear verb and resource: go forward in history. It is understandable on its own, but it does not explicitly distinguish itself from the sibling browser_back tool or any other navigation tools, so it falls short of the top score.

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_back or other navigation tools. The intended use is implied by the action itself, but no explicit context or prerequisites are provided.

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 exact return set, which implies a non-mutating read. However it omits whether the call touches the page state and what happens when tab_id is omitted (null default), leaving key behavior to inference.

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 no filler; the return payload is stated immediately. It is efficient, though arguably compressed to the point of leaving the tab-selection question unaddressed.

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

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

No output schema and no annotations, so the description must carry everything. It adequately conveys the returned metrics but does not cover the undocumented tab_id default or scoping, leaving a real gap for a tool that operates on a specific 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 0% and the single optional parameter tab_id is never mentioned in the description. The agent cannot tell from either source whether omitting tab_id targets the active tab or fails, so the description does not compensate for the schema gap.

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 ('Return document/viewport sizes + scroll position + devicePixelRatio'), which clearly separates it from screenshot and DOM siblings. It is clear about what data comes back, though it never distinguishes itself by name from a neighbouring tool like browser_page_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?

There is no statement of when to call this versus alternatives such as browser_page_info, browser_bounds, or browser_screenshot. Usage is only weakly implied by the returned payload (measuring page dimensions).

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

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

With no annotations, the description carries the full load and does disclose meaningful behavior: the scroll-and-stitch mechanism, a hard 30-viewport cap (a real limitation), that it saves exactly one PNG, and that data_url output is large. It omits permission/auth needs and whether it waits for lazy content, keeping it short of a 5.

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

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

Opening sentence front-loads the mechanism, scope and cap, then a compact Args block covers each parameter. It is efficiently sized, with only minor overlap between the prose mention of saved_to and the Args entry.

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

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

No output schema exists, and the description still tells the agent what it gets back (a saved PNG path via saved_to, optionally a data URL). Combined with the cap disclosure, this is complete enough for a zero-required-param screenshot tool, though auth/error behavior is unaddressed.

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

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

Schema coverage is 0%, so the description must compensate, and it does: tab_id defaults to the active tab, save_to has a concrete default path (~/claude-zen-screenshots/fullpage_<time>.png), and data_url's effect and size cost are explained. It does not restate types, but all three parameters gain meaning beyond the bare schema.

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

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

States a specific verb and resource (scroll-and-stitch screenshot of the full document height) and clarifies scope (up to 30 viewports), which implicitly separates it from browser_screenshot and browser_element_screenshot. It does not name a sibling explicitly, but the 'full document height' framing is enough for an agent to route correctly.

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

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

Usage is implied by the 'full document height' framing, and the description notes that data_url is large, hinting at when to avoid it. However, it never states when to prefer this over browser_screenshot (viewport) or browser_element_screenshot, nor any prerequisites or wait behavior, so guidance remains inferential.

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 and no output schema, the description carries the full burden of behavioral disclosure. It says 'Return,' implying a read operation, but does not describe return format, permissions, side effects, or what the active URL/readonly policy actually contains.

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 sized for a zero-parameter getter.

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 no annotations and no output schema, the description should clarify the return value and usage context. It only names the policy being returned and leaves the output structure and invocation rationale unspecified.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds nothing misleading about parameters, and the empty schema is self-consistent.

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

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

The description states a specific verb ('Return') and resource ('active URL/readonly policy'), making the tool's purpose clear. It implicitly distinguishes itself from browser_set_policy by referring to the 'active' policy, but it does not explicitly name or contrast with that sibling.

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

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

There is no guidance on when to call this tool versus alternatives such as browser_set_policy. It also lacks any prerequisites or context for why an agent would need the active policy.

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 does disclose a real behavioral detail — the return encoding (1.0 = 100%), which matters because there is no output schema — but says nothing about what happens when tab_id is omitted, error behavior, or whether the value is per-tab or per-window.

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 filler. The unit clarification is the highest-value piece of information and it is included without 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?

For a trivial getter with no output schema this covers the return semantics adequately, but the only parameter is undocumented and the tool's tab-scoping behavior is unresolved, which an agent would need to know before calling 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 description coverage is 0% and the single parameter tab_id is never mentioned in the description. The crucial default behavior — that tab_id is optional and presumably falls back to the active tab — is left entirely undocumented.

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

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

States a specific verb ('Return') and resource ('the current zoom factor') and even disambiguates the unit convention (1.0 = 100%). It is clearly distinct from browser_set_zoom by name, but the description itself never names or contrasts that counterpart.

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 text gives no when-to-use, no conditions, and no mention of the obvious alternative browser_set_zoom. Usage is only inferable from the tool name, so this is effectively no guidance in the description body.

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 burden. It usefully discloses the contents of the response (bridge version, ports, keep-alive list, pool state, tags, policy, sessions dir, audit/log sizes), which tells the agent this is a read-only inspection call with no arguments. It stops short of stating read-only/side-effect semantics, cost, or output format explicitly.

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 compact sentence with the subject front-loaded ('Extended health/status') and the payload items listed after the colon. No filler or repetition, though the fragment-without-verb style is terse to the point of being telegraphic.

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

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

There is no output schema, so the description must carry the return-shape burden, and it does list the eight reported categories. Format details (structure, nesting of the health object) are absent, but for a zero-parameter diagnostic tool this is close to sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumerated fields describe the return payload rather than inputs, which is harmless.

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?

Names a specific resource (bridge health/status) and enumerates the concrete dimensions it reports (version, ports, pool state, policy, sessions dir, log sizes). The word 'Extended' implicitly contrasts it with the sibling browser_status, but it never states that relationship explicitly, so sibling differentiation is left to inference.

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 statement and no exclusions. The agent must infer that this is the diagnostic/deep-status call and that browser_status is the lighter alternative; nothing in the text routes it between the two.

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 must carry the full behavioral burden; it does disclose that the effect is a visual overlay, implying no page-state mutation, which is genuinely useful. However it omits whether the highlight persists or must be cleared, whether the element is scrolled into view if off-screen, and what happens if the selector matches nothing or multiple elements.

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 action and effect in one sentence, followed by a compact Args block. The Args block is mildly redundant with the schema but is justified given 0% schema description coverage, so little space 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 simple two-parameter, side-effect-light tool with no output schema, the description covers purpose, both parameters, and the tab-targeting default. The remaining gap is lifecycle behavior (clearing, scroll-into-view, no-match cases), which is minor but not fully addressed.

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

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

Schema description coverage is 0%, so the description has to compensate, and it does: selector is defined as a CSS selector for the target element and tab_id is explained as an optional tab defaulting to the active tab. This fully covers both parameters, though it adds no syntax constraints or multi-match behavior.

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

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

States a specific verb (highlight) and resource (an element on the page) plus the mechanism (visual overlay), which is enough for an agent to know this is a display/debugging action rather than a DOM mutation. It does not differentiate itself from siblings such as browser_element_screenshot or browser_scroll, which an agent might otherwise confuse with a visual element-targeting 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?

There is no statement of when to use this tool versus alternatives (e.g. screenshot, scroll, focus), nor any exclusions or prerequisites. The only usage context, that it targets the active tab unless tab_id is supplied, is parameter guidance rather than selection 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 provided, the description carries the full burden and does little beyond the obvious. It does not disclose whether hovering dispatches real mouseover events, whether the hover state persists, what happens when the selector matches nothing or multiple elements, or whether it waits for the element to be actionable.

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

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

The purpose sentence is front-loaded and the argument list is compact with zero redundancy. The 'Args:' block is slightly mechanical but every line carries needed information given the undocumented 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 simple single-action tool with no output schema, the definition covers the what and the parameters adequately. It is still missing failure behavior and event semantics, which matter for a hover that is often used to trigger menus or tooltips.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning, and it documents both: selector as a CSS selector, and tab_id as optional with a default of the active tab. It does not clarify selector-multiple-match behavior or valid tab_id values, but it compensates well for the empty schema.

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

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

The description states a specific verb and resource ('Hover over an element on the page'), which is unambiguous and distinct from most siblings. It does not explicitly differentiate itself from the closely related browser_click, browser_focus, or browser_blur, but the action itself is clear enough to select correctly.

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 hover versus when a click or focus is more appropriate, nor any mention of prerequisites (element must exist, page must be loaded). The only contextual hint is the tab_id default, which is a parameter detail rather than usage 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?

No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses a 100KB cap, but omits important traits like error behavior for missing selectors, whether it waits for the element, and how the optional tab_id default is resolved.

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 the purpose front-loaded and the size constraint stated second. There is almost no waste, though the two ideas could have been combined more tightly.

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 read tool with two parameters, no annotations, and no output schema, the description should explain return shape (it partially does) and how to target a tab. The tab_id semantics and missing-element behavior are absent, leaving gaps an agent must fill by trial.

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

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

Schema description coverage is 0%, and the description only weakly implies the 'selector' parameter via 'specific element' while never mentioning the 'tab_id' parameter at all. It does not compensate for the undocumented 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 ('Return') and resource ('outerHTML of a specific element'), which is more precise than a generic DOM dump. However, it does not differentiate itself from siblings such as browser_dom, browser_page_text, or browser_wp_html, so an agent must infer the 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 is given, no alternatives are named, and no conditions (e.g., prefer this over browser_dom when you only need one element) are stated. The agent is left to guess based on the tool name alone.

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 discloses part of the return shape (src plus same-origin/accessible flags), which is useful, but says nothing about whether this is a read-only snapshot, which frame context it reads from, or how cross-origin frames are handled.

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 tight sentence with the resource and returned fields front-loaded and zero filler. It is efficient, though the extreme brevity is what leaves the other gaps unfilled.

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

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

With no output schema, the description usefully names the returned fields, which is the minimum needed to predict the result. However, the tab-targeting behavior of the only parameter is left entirely unexplained, so an agent cannot fully call it correctly.

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

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

Schema coverage is 0% and the single tab_id parameter is undocumented in both schema and description. The description never explains that tab_id defaults to null or which tab is targeted when omitted, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('List all iframes') plus the payload fields returned (src, same-origin/accessible flags), which distinguishes it from DOM-scraping siblings like browser_dom or browser_query. It stops short of naming those siblings 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as browser_dom, browser_html or browser_query for frame inspection. The agent must infer the scope from the name alone.

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 return shape (src, alt, natural dimensions), which is meaningful since there is no output schema. However, it says nothing about whether images inside iframes are included, how 'natural dimensions' behave for unloaded/lazy images, or whether the result is scoped to the active tab.

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 no filler; the returned fields are stated immediately. It is arguably too terse rather than padded, but nothing in it 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 no-annotation, no-output-schema tool with one parameter, the description partially compensates by naming the returned fields, but it leaves the tab_id scoping semantics unexplained and gives no guidance on when to pick this tool over the many other extraction siblings.

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

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

Schema description coverage is 0% and the single optional tab_id parameter is completely undocumented in both schema and description. The description does not explain whether omitting tab_id targets the active tab, a default tab, or all tabs, so it fails to compensate for the coverage gap.

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?

Names a specific verb and resource ('Return every <img>') and even enumerates the returned fields (src, alt, natural dimensions), so the agent knows this is an image-extraction tool rather than a generic DOM dump. It is clearly distinguishable from siblings like browser_links, browser_html, and browser_dom, though it never explicitly contrasts itself with them.

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 statement of when to use this instead of browser_dom, browser_html, browser_links, or browser_structured_data, all of which could surface overlapping page content. No prerequisites or context (e.g. page fully loaded) are given, so the agent must infer the use case.

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 defines that 'block' cancels the request and the effect is per-op, but says nothing about persistence/scope (per tab?), invalid-regex handling, or how 'redirect' works given there is no target-URL parameter in 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?

Front-loads the core action in one sentence, follows with a benefit-oriented use case, then a structured Args block. The parenthetical speed-up claim is slightly promotional, but overall the text is tight and well organized.

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

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

For a 3-param tool with no annotations and no output schema, the description covers the inputs but leaves return behavior for 'list'/'log'/'clearLog' unexplained and gives no clue how 'redirect' obtains its destination. Adequate but with real gaps.

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

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

Schema coverage is 0%, so the description does the documenting: it enumerates the five op values, explains patterns as regexes matched against request URLs, and gives the two effect values with a note that they apply only to 'add'. The only gap is the missing redirect target.

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 set of verbs (Block, log, redirect) and the exact resource (HTTP requests by URL regex). It is clearly distinguishable from sibling capture/inspection tools like browser_capture_network or browser_watch_console without opening any schema.

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

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

Gives concrete use cases ('suppress analytics/ads during agent runs' and 'log what an SPA actually fetches') that imply when to reach for it. However, it never names an alternative or a when-not condition, so the agent must infer how it differs from passive capture tools.

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 the result size cap (8 MB, 50 KB on extensions older than 2.1.0) and the slicing behavior of full=True. But it omits whether arbitrary JS executes on trusted/protected pages, error propagation, and whether the return value must be serializable – relevant behavioral facts for an arbitrary-code-execution 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 purpose sentence, then a compact Args block. The full-parameter explanation is slightly long but every clause (cap size, legacy cap, slicing) is decision-relevant. No filler.

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

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

For a 3-param tool with no annotations and no output schema, the description covers the important output-size concern but leaves return-value shape (how a value comes back to the caller) and error behavior unstated. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does: code is explained with two concrete examples, tab_id documents its default-to-active-tab behavior, and full gets a thorough explanation of the capping threshold and sliced read-back. This covers all three parameters well beyond the bare schema titles.

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: 'Execute JavaScript in the current page context'. This is unambiguous and would let an agent identify the tool. However, it does not differentiate from siblings that also read page content (browser_dom, browser_html, browser_query, browser_page_text), so no credit for sibling 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, when-not-to-use, or alternative is named. The agent must infer that this is for arbitrary JS execution rather than the many structured page-reading siblings. The 'tab_id Optional tab to target. Defaults to active tab' line is parameter help, not usage guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses the background pinger mechanism, that it replaces any existing keep-alive for the same tabs, and that the pinger auto-stops on bridge restart. It does not cover return values or failure modes, but the lifecycle behavior is unusually well documented for a side-effecting 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 purpose and mechanism are front-loaded in the first two paragraphs, followed by a workflow recipe and an args block. Everything earns its place, though the Args section is somewhat verbose for a two-parameter tool.

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

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

With no output schema and no annotations, the description usefully covers lifecycle, replacement semantics, defaults, minimums, and the auto-stop on restart. The only gap is what the call returns or how to confirm the pinger is active, which is minor for a keep-alive 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 0%, so the description must compensate and largely does: it explains interval_seconds has a 10s minimum and 60s default, and gives the tuning rationale ('well under Zen's unloader timeout, commonly 20+ minutes'). tab_ids is only restated ('Tab IDs to keep loaded') with no format hint, which holds it below a top score.

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 opens with a specific verb and resource ('Keep tabs warm so Zen's Tab Unloader won't discard them') and explains the mechanism (background pinger firing no-op JS evaluations). It also names its sibling browser_keep_alive_stop and the related browser_parallel, letting an agent distinguish it from generic tab tools.

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 when-to-use recipe: 'Use this at the start of parallel multi-tab work: open your tabs, call browser_keep_alive with their IDs, drive them in parallel... then browser_keep_alive_stop when done.' Both the trigger and the terminating alternative are stated, leaving nothing to inference.

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

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

With no annotations, the description carries the full behavioral burden for a mutation-like action. It never says what happens to the tabs once pinging stops (do they get discarded/suspended?), whether the call is idempotent, or what happens if tab_ids reference invalid/closed tabs.

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?

Very short and front-loaded, with the core action in the first sentence and the parameter behavior second. The Python-docstring 'Args:' style adds a little structural overhead but wastes no words.

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

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

For a one-optional-param tool with no output schema and no annotations, the essentials are present. However, the post-condition (what stopping the pinger means for the tab's lifecycle) is left unstated, which is the main missing element for an agent reasoning about side effects.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that tab_ids identifies 'Tabs to stop pinging' and that omitting or passing null means 'stop all' – matching the schema's default of null and anyOf null type.

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+resource ('Stop the keep-alive pinger') and its scope ('some or all tabs'), so the agent understands exactly what it does. It doesn't name the counterpart sibling browser_keep_alive, but the pairing is obvious from the name.

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 only usage instruction is about the parameter ('Omit (or pass null) to stop all'), not about when to invoke this tool versus alternatives. There is no mention of browser_keep_alive or any condition that selects this tool over others.

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 notes that a synthetic event is dispatched and that text can both key and insert characters, but omits whether events are trusted, whether they respect focus, and any caveats about targets.

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?

Compact and front-loaded with the core action, followed by per-parameter notes. The one missing element is the undocumented tab_id parameter, but the prose itself has 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?

With no annotations and no output schema, the description should disclose return/effect behavior and error conditions. It covers the four main parameters well but leaves tab_id unexplained and says nothing about how the tool reports success or failure.

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

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

Schema coverage is 0%, yet for key, selector, modifiers, and text the description provides names, meanings, examples, and default behavior (selector defaults to document.activeElement). It does not document the tab_id parameter, a minor gap in a 5-param tool with a required key.

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: 'Dispatch a synthetic keyboard event.' This is precise and distinguishable from siblings like browser_type and browser_fill, which imply text entry rather than raw key dispatch.

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

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

The description implies usage through detail (modifiers, text-insertion) but never states when to use this versus alternatives such as browser_type, browser_click, or browser_fill. No when-not guidance or alternatives named.

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 discloses almost nothing: it never states that the operation is read-only, whether it waits for page load, whether links are deduplicated, or how it behaves when no tab_id is supplied. 'Return every anchor' implies a non-mutating read, but that is inference, not 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, front-loaded with the return shape, with no filler. It is efficient, though the terseness is partly under-specification rather than disciplined brevity.

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-parameter tool with no annotations, no output schema, and 0% schema coverage, the description leaves the agent guessing on tab targeting and the meaning of internal_only. The return format is the only thing adequately covered.

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

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

Schema description coverage is 0% and the description adds nothing about either parameter. internal_only is particularly opaque and needs an explanation (same-origin only? excluding external links?) that appears nowhere, and tab_id's default-to-active-tab behavior is likewise unstated.

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 gives a specific verb and resource ('Return every anchor with href + text'), so the agent knows exactly what comes back. It does not, however, distinguish itself from near neighbors like browser_find, browser_query, browser_dom, or browser_html, which an agent could easily confuse for the same job.

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?

'Useful as a crawler primitive' gestures at a use case but names no condition for choosing this over browser_find, browser_query, or browser_html. There is no when-to-use, when-not-to-use, or prerequisite 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?

No annotations are provided, so the description carries the full burden and falls short. 'With their metadata' is the only behavioral hint; there is no mention of ordering, pagination, how many sessions are returned, whether inactive sessions are included, or what happens when no sessions are saved.

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 and no redundancy with the tool name. It is well-formed but so terse that it leaves useful information unstated.

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 listing tool with no annotations and no output schema, the description is minimally adequate but under-delivers: it never says what 'metadata' contains or what an empty result means. Nothing an agent strictly needs to invoke it is missing, but nothing extra helps it either.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool 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 (List) and resource (saved sessions) plus a scope hint ('with their metadata'). It does not explicitly differentiate itself from the sibling session tools browser_save_session, browser_load_session, or browser_delete_session, but the verb choice makes the read-only listing intent inferable.

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, no prerequisites, and no reference to the save/load/delete session siblings. An agent must infer from the name alone that this is the discovery step preceding load_session or delete_session.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it only implies read-only by using "List". It says nothing about side effects, whether mappings are live or cached, or what happens when no tags exist. With no output schema either, the returned structure is only hinted at.

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 short sentence with the resource and return shape front-loaded and no filler. Nothing could be trimmed without losing content.

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

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

For a zero-parameter read of a simple mapping, the description states the return content (tag to tab id) adequately, which matters since there is no output schema. It is nearly complete; only the exact mapping format and empty-state behavior are unspecified.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the schema would not help regardless. Baseline 4 applies for a no-argument tool.

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 a clearly identified resource ("tag → tab id mappings"), which is more precise than the name alone. It implicitly separates itself from browser_resolve_tag and browser_tag_tab, but never names those siblings, so the differentiation is left to inference.

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 context at all: nothing says to call this to enumerate tags before resolving, tagging, or untagging, nor how it differs from browser_resolve_tag or browser_tabs. For a tool with several closely related siblings in the tag/tab cluster, that omission is a real gap.

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 doesn't disclose whether existing cookies/localStorage are overwritten or merged, whether it applies to the current tab or all tabs, or that the operation mutates browser state. Only the mechanical action is 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?

A single, front-loaded sentence with zero padding. It is efficient, though brevity tips into 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 state-mutating tool with no annotations, no output schema, and a completely undocumented parameter, this is insufficient. An agent cannot determine prerequisites, side effects, or the return value from this definition alone.

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

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

Schema coverage is 0% and the single required `name` parameter is undocumented beyond its title. The description does not clarify that `name` refers to a session identifier produced by browser_save_session, leaving the agent to infer the value's origin and format.

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 (restore) and the exact resources affected (cookies + localStorage) from a saved session. An agent can distinguish it from browser_save_session and browser_list_sessions, though it doesn't explicitly name those 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?

No when-to-use guidance, no prerequisites (e.g., a session must already exist from browser_save_session, how to obtain a valid `name`), and no indication of what happens if the session is missing or if the current tab already has cookies.

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 present, so the description carries the full burden. It does usefully disclose the in-memory ring-buffer nature (bounded, ephemeral, older lines dropped), but says nothing about ordering, timestamp format, permissions, or whether the log is per-tab or global.

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 tight sentence with no filler, and the ring-buffer qualifier is front-loaded. It is efficient, though it errs toward under-specification rather than over-verbosity.

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

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

For a tool with no annotations, no output schema, and two entirely undocumented parameters, the one-line description is too thin — an agent has no basis for choosing between it and the console-log siblings or for constructing a valid "since" value.

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

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

Schema description coverage is 0% and both parameters are undocumented. The description explains neither "limit" (default 200) nor "since" (an untyped string with default null, presumably a timestamp or cursor) — format and semantics of "since" are the kind of detail an agent cannot infer.

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?

"Return recent bridge log lines (in-memory ring buffer)" gives a specific verb and resource, but "bridge" is unexplained jargon and the description never distinguishes this from the sibling browser_console_logs or browser_watch_console, leaving the agent unsure which log source it retrieves.

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 at all. With two closely named log siblings (browser_console_logs, browser_watch_console) and a related browser_audit, the description should state whether this covers extension/bridge-side log lines versus page console output, but it offers nothing.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one important trait — the 80KB output cap — which is genuinely useful, but says nothing about which tab is targeted by default, what happens on truncation, or whether this is a read-only 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?

Two short sentences with zero filler, and the core action is front-loaded before the size constraint. 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?

No output schema, no annotations, and 0% parameter documentation. The description omits the return format, default tab behavior, and how the 80KB cap is applied, leaving real gaps for a tool the agent must call blind.

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

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

Schema description coverage is 0%, so the description must compensate. It hints at the selector parameter's meaning ('selector subtree') but leaves tab_id completely unexplained — the agent cannot tell whether null means the active tab or something else.

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?

Clear verb+resource: 'Convert the page (or a selector subtree) to Markdown' tells the agent exactly what the output is. However, it does not distinguish itself from close siblings like browser_page_text, browser_readability, or browser_html, which an agent would also consider for extracting page content.

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 named alternatives, despite several sibling tools (browser_page_text, browser_readability, browser_html, browser_dom) that overlap in purpose. The agent must infer selection from the tool name alone.

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. 'Return all' implies a non-destructive read, but the description never confirms read-only behavior, says nothing about which tab is targeted, and gives no error or rate-limit context.

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

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

A single efficient sentence that front-loads the action and resource with no filler. It is appropriately sized for a simple extraction tool, though one more clause on scope would have cost nothing.

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

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

For a tool with no annotations, no output schema, and an undocumented optional tab_id, the description should at minimum state the target tab behavior and the nature of the read. It leaves both the invocation target and the return shape undefined.

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 schema has 0% description coverage and the single parameter (tab_id, nullable, default null) is never mentioned in the description. The critical question of whether tab_id defaults to the active tab is left entirely unexplained in both the schema and the description.

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

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

States a specific verb ('Return') and resource ('meta tags + link rels') with illustrative examples (canonical, RSS, icons). It is clear what the tool does, though it does not explicitly distinguish itself from close siblings like browser_links or browser_structured_data, which may overlap with the 'link rels' portion.

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 when-to-use guidance, no condition for choosing this over browser_links, browser_structured_data, or browser_page_info, and no prerequisites stated. The agent must infer usage purely from the tool name.

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 the '-1 = end' sentinel convention, which is useful, but says nothing about permissions, whether the move is reversible, what happens to tab focus/active state, or what the response looks like for a mutation 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 compact clauses, front-loaded with the primary action and the window option. Nothing is wasted, though the brevity leaves the sentinel fragment dangling and under-integrated.

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 0% schema coverage, no annotations, and no output schema, the description is the only documentation available. It covers the index sentinel but leaves window_id behavior (does the target window need to exist?) and safety/return behavior unexplained for a state-mutating 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 description coverage is 0% across three parameters. The description partially compensates by explaining that index -1 means 'end', which the schema's raw default does not convey. However, it adds nothing for tab_id (required) or window_id (defaults to null, semantics of moving windows unexplained).

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: 'Move a tab to a position (and optionally to a different window).' An agent can distinguish this from browser_tabs, browser_switch_tab, or browser_detach_tab on the basis of the action described. It stops short of naming or contrasting with those siblings, which keeps it from a 5.

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

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

No when-to-use context at all. It does not say when to prefer this over browser_detach_tab, browser_switch_tab, or browser_pin_tab, nor whether the tab must already exist or be focused. The agent must infer the call context entirely from the name.

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 not say which tab is targeted when tab_id is omitted (presumably active), that 'muted' defaults to true, or whether the operation is idempotent. The only disclosure is the binary toggle itself.

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 short sentence that is front-loaded and waste-free, but its brevity comes at the cost of under-specification rather than genuine efficiency.

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, no output schema, and 0% parameter coverage, the description should at minimum explain tab targeting and the default muted state. As written, an agent must guess both.

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

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

Schema description coverage is 0%, so both parameters are undocumented structurally. The description maps loosely to the 'muted' boolean but says nothing about 'tab_id', including the important fact that a null value presumably means the active tab.

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

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

States a specific verb pair ('mute or unmute') on a specific resource ('a tab'), so an agent knows exactly what effect to expect. It does not differentiate from any sibling, but no sibling overlaps this function, so the gap is minor.

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 muting is appropriate, whether the target must be the active tab, or what happens if the tab is already in the requested state. For a simple toggle this is tolerable but still a clear gap.

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. It usefully discloses the non-obvious 'raw' behavior (bare image URLs open in a local viewer page #zlimg so the extension can script them), which is genuine added context. However it omits key navigation semantics: whether the call waits for page load, timeout behavior, and what happens on invalid 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?

The purpose sentence is front-loaded and the args are listed compactly in a docstring style. The 'raw' explanation runs long but carries real semantic value, so little is wasted.

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

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

For a core navigation primitive with no annotations and no output schema, the definition is only partially complete: it explains arguments but says nothing about post-navigation state (load completion, return value, failure modes) and does not distinguish from the ~30 navigation-adjacent siblings.

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

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

Schema description coverage is 0%, so the description must compensate, and it does document all three parameters: url with a concrete example, tab_id with its default, and raw with a detailed explanation of the viewer-page mechanism. Only per-parameter type/format nuance is missing, so this is strong compensation.

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+resource ('Navigate the active tab to a URL'), so an agent immediately understands this loads a page in an existing tab. It stops short of distinguishing itself from close siblings like browser_new_tab, browser_back, or browser_reload_tab, which would have sharpened selection.

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 guidance or exclusion. The note that tab_id 'Defaults to active tab' hints at multi-tab usage, but it never tells the agent when to prefer this over browser_new_tab or browser_click_and_wait_navigation, leaving routing to inference.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses a non-obvious behavior — bare image URLs open in a local viewer page unless raw=True — but omits whether the new tab becomes focused/active and whether a tab identifier is returned.

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

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

Front-loads the purpose in one line, then documents the two parameters compactly. The Args block is standard and wastes little, though the url default restates the schema default.

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?

Adequate but not complete for a tab-creation tool with no annotations and no output schema: focus behavior, return value (e.g. tab id), and relationship to browser_navigate/browser_switch_tab are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains url's default (blank page) and gives real semantics for raw (bare image URLs open in a local viewer unless raw=True). Only minor gaps, like URL format expectations, remain.

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 ('Open a new browser tab'), which is clear on its own. It does not, however, distinguish itself from close siblings like browser_navigate (navigate current tab) or browser_duplicate_tab, 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?

No when-to-use guidance is given. With ~90 sibling tools including browser_navigate, browser_duplicate_tab, and browser_tabs, the description never says when a new tab is preferable to navigating or duplicating, nor any prerequisites.

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