Bruster

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, but it only states the purpose. It does not disclose that this is a read-only operation, what happens if the attribute or element is missing, whether it waits for the element, or what the return value 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?

The description is a single short sentence fragment with no wasted words, but it is under-specified rather than appropriately concise. It is front-loaded with the core concept, though it lacks the structure needed for an agent to act confidently.

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

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

For a 5-parameter browser-automation tool with no annotations and no output schema, the description is incomplete. It omits return value behavior, element resolution rules, and error conditions, all of which an agent needs to call it correctly.

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

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

Schema description coverage is high at 80%, so the schema already documents ref, tab, selector, and request_timeout. The description adds no parameter meaning, and the required 'name' parameter has no schema description, but the baseline is 3 when the schema does most of the work.

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

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

The description identifies the resource ('attribute value of an element') but is phrased as a noun fragment rather than a specific operation like 'Get the value of a named attribute.' It does not distinguish the tool from siblings such as text, html, or eval, so an agent must infer that this retrieves a single attribute rather than 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?

There is no guidance on when to use this tool versus alternatives like text, html, eval, or snapshot. The description gives no conditions, prerequisites, or exclusions, leaving the agent to guess based on the tool name and schema.

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 what happens at the start of history, whether it blocks until the page loads, whether it affects browser history state, or how it interacts with the current tab. Two words is not enough for a navigation-state mutation with zero annotation coverage.

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 words are technically waste-free but amount to under-specification rather than conciseness; there is no front-loaded purpose sentence or operational detail to compress down to this length.

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 no behavioural detail, the definition leaves the agent unable to predict return values, failure modes, or load-waiting semantics for a history-mutating browser action. Nothing beyond the name and tab param is communicated.

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 optional 'tab' parameter is fully documented in the schema ('tab id, defaults to current'), so schema coverage is 100%. The description adds nothing beyond that, which is the baseline case rather than a strength.

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 phrase 'History back' restates the tool name 'back' with almost no additional specification. Against siblings like 'forward' and 'reload' it weakly implies browser back-navigation, but an agent gets no verb+resource statement and cannot be certain whether this moves a page history pointer, a tab list, or something else.

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 'forward', 'reload', 'navigate', or 'switch_tab'. The agent must infer the alternative and the selection condition 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?

With no annotations and no output schema, the description carries the full burden and discloses almost nothing: it doesn't say whether the operation is idempotent, whether passing checked=false unchecks an element, how 'force' bypasses actionability checks, or what an error/timeout looks like. These are non-trivial behaviors for a mutation tool with 7 parameters.

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 zero waste, but the brevity is under-specification rather than economy — there is no second sentence that earns its place because no second sentence exists.

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, zero-annotation, no-output-schema tool operating in a crowded sibling namespace, this description is far too thin to let an agent invoke it confidently. It should at least cover ref/selector behavior and the semantics of checked and force.

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 only 57%, and the undocumented parameters (force, checked, timeout) are exactly the ones that need explanation. The description adds nothing about ref vs selector precedence, tab scoping, or what checked=false does, leaving the most consequential parameters ambiguous.

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 verb+object pair ('Set a checkbox or radio') disambiguates the generic tool name 'check' into a concrete browser action. It does not, however, distinguish itself from siblings like click, select, or fill, which can also flip a checkbox/radio state, so an agent must infer which to use.

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 over click or select, no prerequisites (does the element need to be visible/in view?), and no note about ref vs selector precedence. Usage is only implied by the word 'checkbox or radio'.

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

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

With no annotations, the description carries the behavioral burden and does add important context: it waits until the target is visible, enabled, and not covered, and force bypasses that. However, it omits other relevant behavior such as scrolling into view, timeout handling, and failure modes.

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 sentences, front-loaded with the core action and the key wait/force behavior. There is no wasted phrasing.

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

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

The description covers the central click semantics and the important wait/force distinction, which is useful for an 8-parameter tool with no annotations and no output schema. It remains incomplete regarding several parameters and error/timeout behavior.

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 50%, and the description adds meaning for x, y, and force. It does not explain ref, selector, tab, timeout, or request_timeout, so several parameters still rely on sparse schema descriptions or no description at all.

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: click an element or a viewport point via x,y. It clearly distinguishes element-based clicking from coordinate-based clicking, though it does not explicitly differentiate itself from sibling interaction tools such as hover or fill.

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 explains what click does but gives no explicit guidance on when to use it versus alternatives like hover, fill, or type. The only conditional guidance is that force skips the visibility/enabled/coverage wait, without saying when that is appropriate.

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

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

With no annotations, the description carries the burden and does disclose the key behavioral fact: this kills all tabs AND the stdio server, i.e., it terminates the session and any unsaved page state. It omits whether that is recoverable, and it never explains how the `tab` parameter interacts with an all-tabs shutdown.

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: the scope-defining action first, the sibling redirection second. Nothing wasted, nothing buried.

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

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

For a one-parameter shutdown tool with no output schema, the essential facts (what dies, which sibling to use instead) are present. The unresolved tension between 'closing all tabs' and the `tab` parameter is the one thing an agent could still get wrong.

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

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

Schema coverage is 100% and the `tab` parameter is already documented there as 'tab id, defaults to current', so the description has no obligation. However, it adds no meaning and arguably conflicts with the schema by implying every tab closes regardless of the parameter.

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

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

States a specific verb ('shut down') and the target ('Bruster'), plus the concrete effect of closing all tabs and the stdio server. It is clearly distinguished from the sibling close_tab. The presence of a `tab` parameter is not reconciled with the 'all tabs' framing, which slightly muddies what is actually being closed.

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

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

Explicitly routes the agent: 'Use close_tab to close only one tab' gives the when-not case and names the alternative. It does not say when full shutdown is preferable (e.g., end of session vs. error recovery), so it stops short of a full 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 present, the description carries the full burden, and it does disclose one meaningful behavioral limit: the last tab cannot be closed. It stops short of saying what an attempt actually does (error, no-op), whether the tab's page state is lost, or whether it acts on the current tab when no id is given.

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 compact sentence that front-loads the action and appends the exception and alternative in a parenthetical. Every clause earns its place.

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

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

For a one-optional-parameter tool with full schema coverage and no output schema, the description supplies enough to call it correctly and know when not to. The only gap is the outcome of a failed close, which is low-stakes for this 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 coverage is 100% and the single `tab` parameter is already documented as 'tab id, defaults to current'. The description reinforces the default-to-current behavior only indirectly via the sibling contrast; it adds no id format, sourcing, or bounds information beyond the schema.

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

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

States a specific verb and resource ('Close a tab') and immediately contrasts it with the sibling `close` tool ('use close to shut down'), so an agent can distinguish the two without opening either schema.

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

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

Gives an explicit constraint-plus-alternative: if the target is the last tab, this tool cannot be used and `close` is the correct routing. It does not mention `switch_tab` as the way to make a non-current tab the target, which leaves one small inference for the agent.

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 helpfully discloses that results are scoped to since the last navigation, but it omits whether reading clears the log, what the clear parameter does, default tab behavior, and any timeout implications.

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 efficient, though extremely terse given the tool's three parameters and lack of annotations.

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

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

For a three-parameter tool with no annotations and no output schema, the description is too sparse. It does not explain the clear parameter's effect, the default tab, or timeout behavior, leaving key invocation details undocumented.

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 67%, and the description adds no parameter meaning at all. The clear parameter has no schema description and no explanation in the tool description, leaving a significant gap that the description does not compensate for.

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 specific resource (console messages and page errors) and adds a temporal scope (since the last navigation), which distinguishes it from siblings like network and dialog. The retrieval verb is implicit rather than stated, but an agent can still identify the tool's purpose.

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 such as network or dialog. The implied use for debugging is present, but no conditions, exclusions, or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden and discloses nothing: no return shape, no whether cookies are for a specific tab or the whole browser, no auth/same-origin caveats, no indication of read-only behavior. Three words cannot cover a browser-state 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?

It is short, but shortness here is under-specification rather than conciseness — there is no front-loaded statement of what the tool does, so nothing is being trimmed for 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?

With no annotations, no output schema, and no explanation of what the returned cookies look like or what "all" covers, the definition leaves an agent unable to predict the result. It should state that it retrieves cookies for the given/current tab.

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

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

Schema description coverage is 100% and the single optional `tab` parameter is documented as "tab id, defaults to current". Per the baseline rule for fully-covered schemas, this scores 3 even though the description adds nothing.

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?

"All cookies." restates the tool name without a verb or scope; it does not say whether it returns cookies, sets them, or clears them. A sibling named set_cookie exists, so the read/write distinction was available but left unstated.

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 at all on when to use this versus set_cookie or any other sibling. The agent must infer the read-vs-write split purely from the tool 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 behavioral burden. It does not state the return type, what happens when zero elements match (0 vs error), whether it waits for elements, or how request_timeout affects a failed match.

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 brevity is efficient, though it borders on under-specification for a tool in a large browser-automation family.

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 explain the return value and edge-case behavior. Instead it leaves the counting domain, return type, zero-match semantics, and timing behavior entirely unstated.

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

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

Schema coverage is only 67%, and the undocumented parameter is the required selector. The description restates that a selector is used but gives no syntax guidance (CSS vs XPath), so it adds almost nothing beyond the schema field 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?

The description names a clear operation and resource: it returns the number of elements matching a selector. That is specific enough to act on, but it never distinguishes itself from siblings such as find or snapshot, which also query the DOM and could plausibly expose counts.

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 prefer count over find, snapshot, or attr, and no mention of prerequisites such as a loaded page or a prior navigation. The agent must infer the entire usage context from the name and sibling list.

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 does disclose a real behavioral trait — persistence across existing and future pages — which is valuable, but it says nothing about whether the setting survives new sessions, whether it is reversible, or how it interacts with the 'tab' scoping.

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 that communicates the action and its scope immediately.

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 one-optional-param tool with a fully documented schema, this is close to adequate, but it leaves open whether the persistence is per-tab or global and how the tab argument modifies the 'all pages' claim, and no output schema exists to cover the return behavior.

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

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

Schema coverage is 100% and the single 'tab' parameter already documents 'tab id, defaults to current'. The description adds no meaning beyond that and actually creates mild ambiguity by claiming the setting applies to all pages while a tab parameter exists.

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

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

States a concrete verb+resource ('Persist dark color-scheme') with a clear scope ('all existing and future pages'). It implicitly differentiates from the sibling 'light' tool via the color scheme named, but never names that sibling explicitly.

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

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

Usage is only implied: an agent can infer this sets dark mode, but there is no statement of when to prefer it over 'light', whether it toggles or is idempotent, or how it relates to the per-tab parameter. No exclusions or alternatives 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?

No annotations are provided, so the description must disclose behavior. It notes persistence for future dialogs but omits whether calls block, how accept/dismiss is determined, what clear resets, and what the listing result 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 compact sentence, front-loaded with the main set operation, and contains no filler. It is terse, but every clause is doing work.

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 five optional parameters, no annotations, no output schema, and low schema coverage, the definition leaves critical behavior and return semantics undocumented. An agent cannot tell what a listing response contains or how prompt text is used.

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 only 40%; only tab and request_timeout are documented in the schema. The description references alert/confirm/prompt generally but does not map accept, text, or clear to concrete behavior.

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

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

The description names specific behaviors: configuring responses to alert/confirm/prompt and listing observed dialogs. It is clear enough to identify the tool, though it does not explicitly distinguish the two modes (setting vs listing) or explain which parameters trigger which behavior.

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 implies persistent configuration via 'from now on' and retrieval via 'list dialogs seen so far,' but gives no explicit when/when-not guidance or prerequisites. No alternative tool is named, and it does not clarify when to use this versus handling dialogs indirectly through other browser actions.

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 one useful trait – that it dispatches HTML5 drag events (dragstart/dragover/drop) rather than raw mouse movement – but says nothing about whether it waits for the drop to complete, what happens on a failed drop, error/silent-failure behavior, or return values.

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 the terseness borders on under-specification for a tool with nested object parameters.

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 nested object params, no annotations, and no output schema, the description leaves too much unsaid: nothing on how targets are addressed, whether the drag is awaited, or what a caller sees on failure. Only the HTML5 event detail fills part of 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 only 50%, covering tab and request_timeout but leaving the two required params (from/to) and their nested ref/selector fields undocumented. The description adds nothing about these parameters or how ref and selector differ, so the most important inputs remain ambiguous.

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 resource (one element onto another), which is unambiguous and clearly distinct from siblings like click, hover, or scroll. The parenthetical '(HTML5 drag events)' sharpens what kind of drag is meant, though it never contrasts with the other interaction tools by 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?

No guidance on when to use this versus click/hover, no prerequisites (e.g. that elements must be draggable), and no note on what to do if the drag fails. The agent must infer the use case 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?

With no annotations, the description carries the full disclosure burden and says nothing about executing arbitrary code, which execution context (main world vs isolated world) it runs in, side effects on page state, or whether the expression's value is returned or serialized. For a code-evaluation tool this is a substantial omission.

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, 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?

No output schema and no annotations mean the description must explain the return value and the behavior of evaluated code, which it does not. An agent cannot tell from this definition what comes back or what risks it takes by 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 coverage is 67%; 'tab' and 'request_timeout' are already documented in the schema. The description only clarifies that the expression is JavaScript, adding little beyond the schema and leaving the required 'expression' parameter's semantics (syntax, awaited promises, return value) 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 states a specific verb and resource ('Evaluate a JavaScript expression') in the page context, making the operation instantly recognizable. It does not differentiate from siblings, but no sibling overlaps with this capability, 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 to use this versus the structured alternatives (text, html, attr, find, snapshot), which cover most read needs. No mention of when evaluation is inappropriate or risky is 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?

No annotations are provided, so the description carries the full disclosure burden. It does earn credit for stating that input/change events fire, which is real behavioral information beyond the schema, but it omits whether existing content is replaced or appended, what force bypasses, and what happens on failure or timeout.

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 core action front-loaded and the event side effect in parentheses – no wasted words. Brevity here comes at the cost of under-specification, but the sentence itself is well-formed.

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 tool with no annotations and no output schema, one line is not enough. Missing are ref vs selector precedence, replacement semantics, force behavior, and any notion of what the tool returns or how it errors.

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 71% with 7 parameters, and the description adds nothing about the three undocumented ones: 'force', 'timeout', and 'value' formats beyond the vague 'set an input's value'. The riskiest parameter, 'force', is left completely unexplained in both description and 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: 'Set an input's value', plus the notable side effect of firing input/change events. It does not differentiate itself from the close siblings 'type' and 'fill_form', which is the main gap at this level.

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 instead of 'type' (keystroke-by-keystroke) or 'fill_form' (bulk), nor any prerequisites such as needing a ref from 'snapshot' or a selector. The agent must infer the choice entirely from sibling 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 exist, so the description carries the full disclosure burden, yet it never says whether existing values are overwritten, whether it waits for navigation or events, how per-field failures are handled, or whether it is atomic. Only the value-type semantics for checkboxes and selects are supplied.

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 sentences with zero filler, front-loading the batch scope and then the payload contract. Nothing is repeated that the schema already states.

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

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

The payload contract and value typing are covered, which is the core need for a form-fill call, and no output schema exists to explain. However, with no annotations and a mutating action, the absence of any note on overwrite, timing, or failure behavior leaves a real gap for an agent deciding how 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 67%, and the description adds real meaning the schema cannot express: the {selector|ref, value} pairing plus type rules that checkboxes take booleans and selects take a value or array. It leaves 'tab' and 'request_timeout' to their schema descriptions, which is acceptable given they are documented there.

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 several fields at once') and shows the batch payload shape, which distinguishes it in spirit from the single-field 'fill'/'type' siblings. It never names those siblings explicitly, so the differentiation is implicit rather than stated.

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

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

'Fill several fields at once' implies the batch case is the trigger, which is a usable cue for choosing this over 'fill'/'type'/'select'/'check'. There is no explicit when-not guidance or named alternative, leaving the agent to infer the boundary.

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, but it only says the tool produces a narrowed snapshot. It does not state that the operation is read-only, whether it has side effects, what the return format looks like, or how matching elements are presented.

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 efficient, front-loaded sentence with no wasted wording. Its brevity is appropriate for conciseness, though it contributes to gaps 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 an 8-parameter tool with no annotations and no output schema, the description is too sparse. It omits most parameter semantics, return shape, tab default behavior, timeout handling, and the relationship to the snapshot sibling.

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

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

Schema description coverage is only 38%, so the description should compensate but does not. It mentions text and regex matching behavior but leaves max, tab, boxes, format, selector, and request_timeout 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?

The description states a specific operation: a snapshot narrowed to elements whose name, text, value, or href matches text or regex. It clearly distinguishes the filtered result from a full snapshot, though the name 'find' is generic and it does not explicitly contrast with the sibling snapshot 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?

Usage is implied: use this when you need only elements matching text or regex rather than a full snapshot. However, it gives no explicit when-to-use/when-not guidance, no alternatives, and no prerequisites.

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 entire burden, yet it discloses nothing: no mention of what happens when there is no forward history, whether the call fails or is a no-op, whether it waits for page load, or whether it changes active tab state. Two words provide zero behavioral context for a state-changing navigation action.

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 technically terse, but this is under-specification rather than conciseness. The two-word fragment is front-loaded in the sense that there is nothing else to follow, yet it fails to earn even that space by conveying actionable information.

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

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

The tool is simple (one optional param, no output schema), which lowers the bar, but for a navigation action with no annotations the description should still say what state change occurs and what the response looks like. It provides none of that, leaving the agent to guess behavior.

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 optional 'tab' parameter is fully documented in the schema (100% coverage) with 'tab id, defaults to current', so the schema does the heavy lifting. The description adds nothing about the parameter, which matches the baseline 3 for high schema coverage.

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

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

"History forward." essentially restates the tool name 'forward' with the noun 'history' attached; it never states that this navigates the browser's forward history or what page state results. Sibling tools like 'back' and 'reload' make browser navigation plausible, but the description itself barely adds specificity beyond the identifier.

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 whatsoever on when to use this versus 'back', 'navigate', 'reload', or 'switch_tab'. The agent must infer that this is the inverse of 'back' and that it should be used only when forward history exists.

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 but discloses nothing: it does not say whether hovering waits, scrolls the element into view, triggers tooltips/menus, what force means, or how timeouts behave. It is not contradictory, but it is essentially silent on behavior.

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 only two words, but this is under-specification rather than useful conciseness. There is no front-loaded context about what hovering does or how to invoke it correctly.

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 six-parameter browser automation tool with no annotations and no output schema, a two-word description is completely inadequate. An agent cannot determine targeting strategy, timeout behavior, or side effects from this definition.

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 moderate at 67%, with ref, tab, and selector documented in the schema, while force, timeout, and request_timeout are undocumented. The description adds no meaning beyond the schema and does not clarify targeting precedence between ref and selector.

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

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

The description names a specific verb and resource ('Hover an element'), so the basic action is clear. It does not distinguish hover from sibling element interactions such as click, drag, or scroll, and it gives no scope or intended effect.

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 hover versus alternatives like click or find. No preconditions, no mention of how to target the element, and no exclusions 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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read operation but does not state what happens when the element is missing, whether refs expire after navigation, how large the returned markup may be, or how the call interacts with the tab/session — all meaningful for a browser-inspection tool.

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

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

It is short, but this is under-specification rather than conciseness: a four-word noun phrase with no verb and no front-loaded cue about which parameter to use. Brevity here costs the agent actionable context.

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

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

For a tool with four optional parameters, no annotations, and no output schema, the description should at minimum say how the target element is identified (ref vs selector) and roughly what comes back. Neither is covered, so it is not complete enough to call reliably.

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

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

Schema coverage is 100%, so each of ref, selector, tab, and request_timeout is already documented in structured fields, making 3 the baseline. The description adds nothing beyond that — notably it does not resolve the real ambiguity that all four params are optional, leaving unclear whether ref or selector (or neither) is required to identify the element.

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 fragment "outerHTML of an element" identifies the resource returned but omits an explicit verb and gives no differentiation from close siblings such as text (inner text), attr (attribute values), or eval. An agent can infer it retrieves serialized HTML markup, but only by 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?

There is no guidance on when to choose this over text, attr, or eval, and no mention of when NOT to use it (e.g., for large subtrees where text or a targeted attr call would be cheaper). Nothing tells the agent which of ref or selector to supply.

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

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

With no annotations, the description carries the full burden. It does disclose the important behavioral trait that the change persists across all existing AND future pages, but says nothing about reversibility (calling 'dark'), whether the setting is per browser context, or whether a reload is needed for existing pages.

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 with the action and scope front-loaded and no wasted words. Slightly terse for a state-changing tool, but structurally sound.

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

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

For a one-parameter, no-output global preference toggle this covers the essentials, but omits how to revert the change and whether the persistence is per-tab, per-context, or global, which matters given the 'tab' parameter.

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

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

Schema coverage is 100% and the single 'tab' parameter already documents itself as defaulting to the current tab. The description adds nothing about 'tab' and its 'all existing and future pages' phrasing is neutral-to-slightly-tensioned with a tab-scoped parameter, so baseline 3 applies.

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

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

States a specific verb ('Persist') and resource ('light color-scheme') plus the scope of effect. It is implicitly distinguished from the sibling 'dark' tool by naming the light scheme, though it never explicitly says 'use dark to switch back'.

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 scope clause ('all existing and future pages') implies this is a global preference toggle, from which an agent can infer the dark counterpart, but there is no explicit when-to-use/when-not statement or named alternative.

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 a side effect beyond the immediate action (persisting the mode for future runs) and an edge case (hidden windows only persist), but it never explains what 'requested mode' refers to given the sole parameter is a tab id, nor what the call returns.

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

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

Two short sentences, front-loaded with the action and followed by the persistence semantics and the exception. No wasted text.

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

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

For a zero-required-parameter, single-action tool with no output schema, the description covers the action, the persistence side effect, and the hidden-window exception. Only the meaning of 'requested mode' relative to the 'tab' parameter is left 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 100% for the single optional 'tab' parameter, so the baseline is 3. The description adds nothing about the tab parameter and even frames the action as window-scoped while the schema is tab-scoped, leaving that relationship to be inferred.

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 ('Maximize') and resource ('this window'), which is unambiguous against siblings like resize, minimize, and close. It stops short of explicitly naming the alternative dimensioned tool (resize) for resizing to arbitrary bounds, so it is clear but not 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?

Usage is implied by the verb and by the caveat that hidden windows only persist the mode, which tells the agent the visible effect is conditional. There is no explicit when-to-use versus resize/minimize guidance or prerequisite statement.

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 does the important work of disclosing that the window is only hidden off-screen and the mode persists, implicitly reassuring that nothing is destroyed. It does not say whether the page keeps running, whether subsequent tools can still target the hidden window, or whether 'persist' survives across sessions — gaps that matter for an unannotated tool.

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

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

Two short sentences, front-loaded with the action. The second sentence partly restates 'persist minimized mode' as 'only persist the mode', a mild redundancy but not enough to bloat the definition.

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

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

For a one-optional-parameter tool with no output schema and no annotations, this is roughly adequate, but it leaves open what happens to an already-hidden window, how the tab argument interacts with the window, and whether hidden windows remain interactable.

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

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

Schema coverage is 100% ('tab id, defaults to current'), so the baseline applies. The description adds nothing about the tab parameter, and notably never addresses why a window-level operation takes a tab id — a point the description could have clarified.

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

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

The description names a specific verb and resource ('Hide this native window') plus the state effect ('persist minimized mode'), which is enough to distinguish it from sibling 'maximize' and from 'close'/'close_tab'.

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?

'Hidden windows stay off-screen and only persist the mode' implies the use case (reversibly getting a window out of the way without closing it), but there is no explicit when-to-use, no when-not, and no naming of 'close' or 'maximize' as the alternatives an agent should weigh.

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 explains the waiting semantics of load, dom, and idle, but omits side effects, timeout behavior, and what the tool returns after navigation.

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

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

The description is front-loaded and compact, with the core action first followed by the key parameter explanation. The phrasing 'wait for it. until:' is slightly awkward but not wasteful.

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 no annotations or output schema, the description covers purpose and the most important enum parameter. It still leaves gaps around tab targeting, timeout handling, and post-navigation return behavior.

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 only 50%, and the description compensates partially by explaining the 'until' enum values in richer terms than the schema. However, it does not add meaning for 'tab' or 'timeout', leaving half the parameters undocumented beyond the schema.

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

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

States a specific verb and resource: open a URL and wait for it. This clearly distinguishes the core navigation action from sibling tools like reload, back, and click, though it does not explicitly name those alternatives.

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

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

The description gives useful guidance for choosing the 'until' value, such as 'dom' being fastest and fine for server-rendered pages, but it does not say when to use navigate versus reload, forward, back, or other navigation-related siblings.

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

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

With no annotations, the description carries full behavioral burden and discloses almost nothing. It does not say whether requests are captured live or from a buffer, what the 'clear' parameter destroys, whether repeated calls accumulate or reset data, 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?

It is very short, but the structure is two cryptic fragments rather than a front-loaded statement of purpose. The second sentence 'index feeds network_request' is unexplained and does not earn its place without further context.

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

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

This is a tool with three parameters, no annotations, no output schema, and an undocumented destructive-sounding 'clear' parameter. The description leaves critical gaps about behavior, return shape, and reset semantics that an agent needs in order to invoke 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 67%: 'tab' and 'request_timeout' are documented in the schema, but 'clear' has no schema description at all. The tool description provides no parameter meaning beyond the vague 'index feeds network_request,' so it fails to compensate for the missing 'clear' semantics.

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

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

The description identifies the resource as page network requests and names fetch, xhr, and resources, but never states the action clearly (list, capture, inspect?). The phrase 'index feeds network_request' hints at a relationship with the sibling tool but does not clarify what this tool itself returns or does.

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 the sibling network_request. The only relational clue is 'index feeds network_request,' which is too terse to tell an agent when this is the correct choice.

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, but it does disclose useful behavior: the response includes headers and a body prefix, implying the body is truncated. It does not state permission requirements, truncation limits, or error behavior.

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 efficient sentence with no redundant content. It is front-loaded with the resource type and scope, though it is too terse to support correct invocation.

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 tool with three parameters and no output schema, the description is incomplete. It omits how to obtain the required index and does not clarify body-prefix truncation, which is central to interpreting the result.

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 67%, and the required 'index' parameter is undocumented in both schema and description. The phrase 'one fetch/xhr entry' implies index selects an entry, but it does not explain where index comes from or how it maps to the network listing.

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 the specific resource it retrieves: 'Headers and body prefix of one fetch/xhr entry from network.' This distinguishes it from the sibling 'network' tool, which likely lists entries, but the action verb is implicit rather than explicit.

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

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

The description gives no explicit when-to-use guidance or alternatives. It does not tell the agent to call 'network' first to obtain an entry index, nor does it explain when to choose this tool over other network-related siblings.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the tab is not made current and that an id is returned, but says nothing about timeout behavior, whether the call blocks until page load, or failure behavior for invalid URLs. Solid but incomplete 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 tight sentences, front-loaded with the action and followed by the return value and the follow-up call. Zero 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?

Return value is covered despite no output schema, and the switch_tab follow-up is noted. However, with two of three parameters undocumented and no annotations, the description leaves timeout and tab-selection behavior 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 only 33% — only 'tab' has a description. The description adds that the URL is optional (already implied by required=[]) but never explains the 'timeout' semantics or what 'tab' means when creating a new tab. It 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?

States a specific verb and resource ('Open a new tab') plus the URL option, which clearly separates it from switch_tab / close_tab / tabs siblings. It stops short of 5 because it doesn't clarify how the 'tab' parameter relates to opening a *new* tab.

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

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

Explicitly routes the agent: opening does not focus the tab, and switch_tab must be called to make it current. That is actionable sequencing guidance. No explicit exclusions or prerequisites (e.g., browser session state) 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?

No annotations, so the description carries the entire burden, and it discloses almost no behavior: nothing about whether the key goes to the page, the focused element, or the element identified by ref/selector, nor what happens on failure or timeout. Only the key format is conveyed.

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 arguably so terse that conciseness shades into under-specification.

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

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

For a five-parameter input tool with no annotations and no output schema, the description leaves important behavior undefined: which element receives the key, how ref/selector/tab interact, and whether an error is returned if the target is missing.

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

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

Schema coverage is 80%, so the schema already documents ref, tab, selector, and request_timeout, establishing the baseline of 3. The description's examples add genuine meaning for the required key parameter (key-combo syntax like 'Control+a'), but the targeting parameters are not clarified further.

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 ('Press a key') with concrete examples of key values, so the agent knows this is keyboard input rather than text entry. It doesn't explicitly contrast with the close siblings 'type' and 'fill', which is the main gap.

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 examples (Enter, Escape, Tab, Control+a) imply shortcut/mnemonic use versus typing content, which is useful implicit guidance. There is no explicit statement of when to use this instead of 'type'/'fill', or prerequisites such as needing an element focused first.

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 at all, so the description carries the full burden: it never states that this is a read-only lookup, what happens when the element is missing, which of ref/tab/selector wins if multiple are supplied, or what the returned box looks like. Only the timeout parameter's schema hints at page-load behavior.

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 front-loads the result and appends the purpose. It is efficient, though as a noun-phrase fragment it omits an explicit verb and reads more like a return-type note than an instruction.

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 and no output schema, the description should describe the returned geometry and failure modes; it does neither. An agent knows roughly what it gets but not its shape or error behavior, which matters when feeding the result into a screenshot clip.

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

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

Schema description coverage is 100%, so each of the four parameters is already documented (ref example, tab default, selector, timeout default). The description adds no meaning beyond that baseline, in particular no precedence rule among ref/tab/selector.

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

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

States a specific resource and result — the bounding box of an element — and the parenthetical clarifies the intended consumer (screenshot clip). It is distinguishable from siblings like screenshot or snapshot, though it never names them or says what a 'bounding box' contains.

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 'for screenshot clip' implies the intended workflow but gives no explicit when-to-use or when-not guidance, nor does it say to obtain a ref via snapshot first (only the schema hints at that). An agent must infer the sequence rect -> screenshot itself.

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 state whether the call blocks until the page finishes loading, whether it discards unsaved form state or scroll position, or whether it requires the tab to be focused. Those are exactly the behaviors an agent needs before triggering a reload.

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 four-word imperative sentence, front-loaded and waste-free. It is arguably too terse for the behavior it triggers, but there is no structural or verbosity problem.

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

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

The tool is simple (one optional param, no output schema, no nested objects), so the description is close to adequate. It still leaves open the load-wait and state-loss questions, which matter for a reload operation but are lower-stakes than for a complex tool.

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

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

There is one optional parameter (tab) and the schema documents it at 100% coverage, including its 'defaults to current' behavior. The description adds nothing about the parameter, which is acceptable given the schema baseline, but it misses the chance to clarify current-tab versus background-tab semantics.

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

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

"Reload the page" names a specific verb (reload) and resource (the current page), so an agent immediately knows the operation. It does not distinguish itself from related siblings such as navigate, back, or forward, which is the only thing keeping 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?

The description gives no guidance on when to reload versus using navigate/back/forward, nor any exclusions or preconditions. 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 are provided, so the description carries the full behavioral burden. It omits units (likely pixels), minimum/maximum dimensions, whether it affects only the current tab, whether it triggers reflow or resize events, and whether the change persists.

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 filler. It is concise, though arguably too terse for a three-parameter viewport operation.

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

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

With no annotations, no output schema, and incomplete parameter documentation, the description should explain units, constraints, tab behavior, and expected effect. It leaves all of that unspecified, so an agent cannot reliably invoke the tool without inspecting the schema or guessing.

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 only 33%: only the tab parameter is documented as defaulting to the current tab. Width and height have no descriptions, and the tool description adds no unit, range, or constraint semantics beyond the word 'resize', so it fails to compensate for the missing schema detail.

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 (resize) and resource (viewport), reinforced by the width/height parameters. It is clear what the tool does, but it does not explicitly distinguish itself from the maximize/minimize 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?

Provides no guidance on when to use resize instead of maximize or minimize, nor any prerequisites such as needing an active tab. Usage is only implied by the tool name and action verb.

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 does disclose two useful behavioral facts — the default scope is viewport-only unless full=true, and the image is returned inline unless path is given — but it omits what is actually returned when path is set (a path string? nothing?), and whether the capture waits for load or handles lazy content.

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 dense sentence with the output format front-loaded, followed by the two mode switches. There is no filler and every clause carries operative information.

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

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

For a simple read-only capture tool with no annotations and no output schema, the description covers the essential modes but leaves the return contract ambiguous when path is used, and says nothing about load timing or failure modes. Adequate but with visible 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 only 25%, so the description must compensate, and it mostly does: it explains full, the clip rectangle shape, and the path/return trade-off, none of which the schema documents. The only uncovered gap is that clip coordinates/pixel units and the tab parameter's default are left to the schema.

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

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

The description states a specific resource and output format: a PNG image of the current viewport, with optional full-page or clipped variants. It is clear what the tool produces, but it never distinguishes itself from nearby siblings like snapshot, html, or text, which an agent could plausibly confuse with it.

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

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

'full=true for the whole page, or clip={...}' gives parameter-level selection guidance, and 'path writes the file instead of returning it' explains the return-mode choice. However, there is no guidance on when to reach for screenshot versus snapshot/html/text, and no prerequisites or exclusions are stated.

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

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

No annotations, so the description carries the full burden and falls short: it does not say which surface scrolls, what happens when neither mode is supplied, which takes precedence if both are, or whether scrolling waits for completion. The mode split is the only real behavioral 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?

A single front-loaded sentence with no filler. Brevity is appropriate, though it is under-specified rather than tight.

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?

Six optional parameters, no annotations, and no output schema — the description should explain precedence between element and coordinate modes and the default behavior with no arguments. Neither is covered, leaving real ambiguity for a zero-required-parameter tool.

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

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

Schema coverage is 67% and the description only implies semantics for ref/selector (element mode) and x/y (coordinate mode); selector, tab, and request_timeout get nothing extra from the description. Roughly baseline for partial coverage.

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

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

States a specific verb (scroll) and the two targeting modes (element into view, or by x/y), which is enough to distinguish it from every sibling in the list — none of which scroll. Lacks any statement of target surface (page vs. scrollable container).

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 indication of which mode to pick when — though the two modes are named. An agent has to infer that ref/selector selects element mode and x/y selects pixel mode.

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 the behavioral burden. It says only that options are chosen, without disclosing side effects, event firing, visibility requirements, force behavior, timeouts, or whether the element needs a ref. This is minimal transparency for a mutation-style browser action.

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 filler. It is appropriately concise, though its brevity leaves important context to other dimensions rather than providing structured guidance.

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 seven parameters, no annotations, and no output schema, the description is too thin. It omits how to target the element via ref or selector, what force does, timeout behavior, and expected side effects, leaving an agent with significant 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 moderate at 71%, with descriptions for ref, tab, value, selector, and request_timeout. The tool description adds nothing beyond echoing 'option(s)', and it does not clarify force, timeout, or the choice between ref and selector. The schema does most of the work.

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

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

The description gives a clear verb and target: choose option(s) in a <select>. This makes the tool's purpose immediately understandable. It does not explicitly differentiate from siblings like click, fill, or check, 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention selecting between ref and selector, when to use force, or how it differs from click/fill/check. Usage is only implied by the phrase 'in a <select>'.

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 discloses almost nothing. It does not say whether an existing cookie with the same name/domain/path is overwritten, what defaults apply for path/domain/tab, whether the cookie is session-only or persistent, or whether it requires an active page 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?

It is short, but brevity here is under-specification rather than conciseness — the single sentence conveys no information beyond the tool name. Nothing is front-loaded because there is nothing to front-load.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the definition supplies none of the information an agent needs: no defaults, no overwrite semantics, no origin/context requirements, no mention of the sibling read 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 only 40%: name, path, domain, and value have no schema descriptions, and the description adds no meaning for any of the five parameters. Notably it does not clarify the multi-select array form of value or the path/domain defaulting behavior, both of which materially change the resulting cookie.

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?

"Set a cookie" restates the tool name almost verbatim and adds no scope detail: it does not say whether it writes a cookie into the browser context of the current page, a specific tab, or a domain. The sibling "cookies" (presumably the read counterpart) is not referenced, so an agent gets no differentiation signal beyond the verb.

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 versus reading cookies via the sibling "cookies" tool, nor any prerequisite (e.g., page must be navigated first, cookies only settable for the current origin). Usage is only inferable 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 discloses output format ('one per line: ref role "name" href=...') and the effect of some parameters, but does not state that the operation is read-only, whether it waits for page stability, permission requirements, or error behavior.

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 dense sentence with no filler, front-loading the purpose before listing parameter effects. Slightly run-on, but every clause adds useful information.

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

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

For a six-parameter tool with no output schema and no annotations, the description explains the return format and covers the key optional parameters. It omits details on tab selection and timeout behavior, but those have schema descriptions and the core usage is clear.

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 only 50%, and the description fully compensates for the three undocumented parameters: 'max caps the list', 'boxes adds rects', and 'selector scopes to a subtree'. It also adds meaning beyond the schema for format by explaining 'json for objects'.

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 'visible elements and text with refs usable in other tools', making it clear this returns interactive element references rather than raw text or HTML. The mention of 'refs usable in other tools' distinguishes it from siblings like text, html, and count.

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 for obtaining element refs for later actions, but does not explicitly say when to use this instead of find, text, or html, nor does it state any exclusions or prerequisites. Usage 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 load. It does disclose the key behavioral trait — the change persists as the default for later calls — but says nothing about whether the tab is focused/activated, prerequisites, or failure behavior for an invalid id.

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 with the effect front-loaded and no waste. It errs toward under-specification rather than 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 single-parameter tool with no output schema and no annotations, the core effect is captured, but practical context an agent needs — source of the tab id and behavior on invalid ids — is missing.

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

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

Schema description coverage is 100%, so the 'tab id, defaults to current' documentation is already in the schema, and the description adds no further meaning. Baseline 3 applies.

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

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

States a specific action and effect: making a given tab the default target for subsequent calls. This distinguishes it from listing tabs (tabs), opening (new_tab) or closing (close_tab), though a reader must infer the default-target semantics from 'default for later calls' rather than an explicit statement of switching the active tab.

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

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

No guidance on when to call it versus tabs, new_tab, or navigate. It does not say where the tab id comes from (presumably the tabs tool) nor what happens if the id is unknown — an agent must guess.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing beyond the one-line purpose: return shape (ids? titles? urls?), ordering, whether background tabs are included, and the fact that it's a read-only operation are all unstated.

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

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

A three-word, front-loaded sentence with zero waste. It is terse rather than bloated, though the terseness borders on underspecification.

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?

This is a trivial zero-required-parameter read tool with a fully described schema and no output schema, so minimal description is defensible. However, for a listing tool the shape of the returned list is the key unknown and is never 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 100% and the single parameter ('tab id, defaults to current') is already documented in the schema, so the description adds no parameter meaning. Baseline 3 is appropriate.

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

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

Specific verb+resource: 'List open tabs' tells an agent exactly what it does, and the verb distinguishes it from new_tab/switch_tab/close_tab. It does not explicitly contrast with those siblings, but the naming makes the distinction 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 guidance on when to call this vs. switch_tab/new_tab/close_tab, and no note about whether the optional 'tab' argument is meaningful for a listing operation. 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?

With no annotations, the description carries the full burden, but it does usefully disclose truncation to max characters — context the schema does not provide since the max property has no description. It omits what happens when neither ref nor selector is supplied, which element wins on multiple matches, and failure behavior, leaving significant gaps for an unannotated tool.

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

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

A single front-loaded sentence with no filler, and the truncation caveat is attached directly to the resource. The terseness borders on under-specification rather than excess, but nothing written is wasteful.

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?

Five optional parameters, no annotations, and no output schema mean the description should explain element targeting and defaults, yet it only covers what innerText returns and that it truncates. An agent must guess how ref, selector, and tab interact before it can call this 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 80%, so most parameters are already documented, and the description compensates for the one gap by explaining that max truncates output. It says nothing about ref/selector precedence or tab targeting beyond what the schema states, so this is the baseline.

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

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

The description names a specific extraction action and resource ("innerText of an element") plus its truncation behavior, so an agent knows exactly what is returned. It does not distinguish itself from sibling readers like html, attr, or eval, which would be needed for 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 statement of when to use this instead of html, attr, snapshot, or eval, and no guidance on the ref-vs-selector choice that determines which element is read. Usage must be inferred 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 are provided, so the description carries the full burden, yet it discloses nothing about read-only behavior, return shape (a string? an object?), or what happens when the tab is closed or missing. It is at least not misleading, but it adds no behavioral context beyond the title.

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?

Extremely short, but this is under-specification rather than concision: two words carry no verb, no scope, and no return information. Nothing is front-loaded because there is essentially nothing to front-load.

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

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

The tool is simple with no required parameters, but there is no output schema and no annotations, so the description should at minimum say what is returned and from which page/tab. It leaves the agent to guess the return type and whether the call is a safe read.

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

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

Schema description coverage is 100%, with both the tab default and the request_timeout semantics documented in the schema itself. The description adds nothing beyond that, so the baseline of 3 applies.

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

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

"Page title." merely restates the tool name as a noun phrase and never supplies a verb, so it is ambiguous whether the tool returns the title, sets it, or checks it. It also gives no differentiation from sibling readers like url, html, or text.

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

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

There is no indication of when to call this instead of siblings such as url or html, nor any precondition, exclusion, or typical workflow context. Usage is only inferable from the name itself.

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 behavioral load. It usefully discloses that input is simulated keystroke-by-keystroke and that submit triggers Enter, which are meaningful behavioral traits. It says nothing about focus requirements, error behavior when the element is missing, or what delay/force/timeout actually do, leaving major gaps for a 9-parameter mutation-style 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 then the submit modifier. 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 tool with 9 parameters, 44% schema coverage, no annotations, and no output schema, the description is far too thin. An agent cannot tell whether ref or selector is preferred, what force/delay mean, or what happens on timeout or missing elements.

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 only 44% across 9 parameters. The description explains only submit (and implies text); it adds no meaning for ref vs selector, delay, force, tab, timeout, or request_timeout. It does not compensate for the low structured coverage as required.

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 ('Type text key by key into an element') and clarifies the submit modifier. The 'key by key' phrasing implicitly distinguishes it from bulk-fill siblings like fill, but it never names fill or fill_form 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 'key by key' framing implies when to prefer this over a one-shot fill, and the note that 'submit presses Enter afterwards' gives a usage hint. However, there is no explicit guidance on when to use type vs fill/fill_form or any stated exclusions/prerequisites such as element focus.

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: it doesn't say whether the change/input events fire, whether the element must already exist, what happens if paths are invalid, or that it mutates page state. Only the implicit fact that this is a write to the page is conveyed.

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 with the target and the input source front-loaded; nothing wasted. It is arguably too terse, but that gap is captured under other dimensions rather than penalized here.

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

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

For a 5-parameter browser-automation mutation with no annotations and no output schema, the description is far too thin; it never explains the page/tab targeting model, selector defaults, or failure behavior. An agent can guess the call shape from the schema but not the operational context.

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

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

Schema description coverage is 100%, so ref, tab, paths, selector and request_timeout are already documented in the schema. The description only reinforces the 'local paths' meaning of the required parameter and adds nothing about selector resolution or tab scoping.

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: 'Set files on a file input' from 'local paths', which is meaningfully distinct from the fill/type siblings that handle text entry. It doesn't explicitly name the sibling it replaces, but the 'file input' target makes the distinction 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 guidance on when to use this instead of fill or fill_form, and no preconditions stated (e.g. that the target element must be an <input type=file>, or that a snapshot/ref should be taken first). The agent must infer usage entirely from the name and schema.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses nothing: no statement that it is a side-effect-free read, no return format (string? object with tab id?), no note on how the `tab` default resolves, and no behavior when no tab/page is loaded.

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 words is not conciseness, it is under-specification; there is no front-loading problem but also no content that earns its place. The brevity removes information rather than waste.

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?

In a 40+ tool browser automation suite, an agent needs to know this returns the current page URL (a read) versus navigating to one, and how it interacts with the `tab` parameter. With no output schema and no annotations, the description leaves all of that 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 100% — the schema already explains `tab` (defaults to current) and `request_timeout` (deadline in ms). The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

"Current URL." is essentially a restatement of the tool name with no verb or stated action — it never says it *returns/reads* the URL of the page or tab. Among siblings like `navigate` (which sets a URL) and `html`/`text`/`title` (which return page content), an agent can infer the read semantics but only by guessing.

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. It does not distinguish itself from `navigate` (URL mutation) or `new_tab`/`switch_tab`/`tabs` (tab addressing), which is the exact ambiguity an agent would face here.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not say what happens on timeout (error vs. silent return), what the default timeout is, whether the call blocks, or whether the supplied conditions are OR'd or AND'd. For an 11-parameter waiting primitive with zero annotation coverage, these are significant omissions.

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 parenthetical enumeration keeps it compact. It is arguably too terse for the parameter surface it must cover, 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?

With 11 optional parameters, no annotations, and no output schema, the description should explain timeout expiry behavior and condition-combination semantics. It instead only lists conditions, leaving an agent unable to predict the tool's failure mode or resolution rules.

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 only 36%, but the description does partially compensate by mapping the condition types to parameters: state/selector, text, textGone, url, idle, and time are all named. It adds nothing for ref, tab, timeout, or request_timeout, and leaves the distinction between timeout and request_timeout 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 and enumerates the six distinct wait conditions (selector state, text present/gone, url substring, network idle, time ms), which is far more than the name alone conveys. It is clearly distinguishable from action siblings like click or snapshot. It stops short of explaining how the conditions relate to one another when several are supplied.

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 enumerated conditions hint at post-navigation / async-page synchronization, but there is no statement about when to prefer wait_for over polling with a sibling, nor when not to use it. No guidance on which condition to choose for a given page-state problem.

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