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 several useful traits: native interaction, no replay or hidden observe, and that select is native HTML only. It still omits side effects, navigation/submission behavior, and failure modes, so significant gaps remain 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?

The description is short, front-loaded, and every sentence contributes: purpose first, then a negative behavioral constraint, then a select-specific rule. It is appropriately terse, though it is arguably under-specified for a tool with a complex oneOf schema.

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

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

Given the tool's complexity (7 parameters, a nested oneOf, required fields, no annotations, and no output schema), the description is too thin. It does not explain how to form valid parameter combinations, what the tool returns, what side effects to expect, or when to prefer alternative tools.

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

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

Schema description coverage is only 29%, so the description must compensate but mostly does not. It names the action values and constrains ref to an observed ref, yet it never explains the required value/key/label combinations for fill, press, and select, nor the role of tab_id and timeout beyond what little the schema itself provides.

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

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

The description states a specific set of actions (click/fill/press/select) on a specific target (an exact observed ref), which is much clearer than a generic verb. It does not name sibling tools or explicitly route the agent away from observe, so it falls short of full sibling differentiation.

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 context by requiring an 'exact observed ref' and stating 'No replay or hidden observe,' which tells the agent this tool does not perform observation. However, it does not explicitly say when to use this versus siblings like observe or goto, nor does it list exclusions or prerequisites in a routing-friendly way.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: requests are scoped to a tab's cookie jar, output is streamed and written atomically, and no Save dialog appears. It is silent on failure/partial-write behavior, permission or auth requirements, and concurrency, which matters for a mutating filesystem operation.

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

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

Two tight clauses with zero filler and the key constraints front-loaded. The telegraphic, semi-sentence style trades some readability for density, but every phrase carries 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 7-parameter write-to-disk tool with no annotations and no output schema, the description covers the core semantics and the hard limitations but omits error behavior, overwrite/directory-creation consequences, and size-limit behavior. 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 description coverage is 57%, with mkdir, max_bytes, and overwrite carrying no description anywhere. The description's "cookie-scoped" and "no implicit tab selection" framing adds meaning to tab_id and url beyond the schema, but it says nothing about the undocumented three parameters, so it only partially compensates for the gap.

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

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

The description names a concrete mechanism (cookie-scoped HTTP GET streaming to an atomic file write), which is clearly distinct from browser-rendering siblings like goto or screenshot. It never explicitly contrasts itself with those siblings, so an agent has to infer that this is the file-retrieval path rather than rendering, but the purpose itself is specific and non-tautological.

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 POST/blob/challenge fallback" gives explicit negative conditions (don't use for POST endpoints, blob URLs, or challenge-protected resources), which is genuinely useful routing information. However, it names no positive trigger and no alternative tool to use for the excluded cases, so the when-to-use guidance is only half complete.

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

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

No annotations are provided, so the description carries the full burden. 'No hidden observe' is a genuine behavioral disclosure (navigation does not implicitly observe), but it omits what navigation actually does, whether it waits for load, and what state results. Partial disclosure only.

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

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

Two short sentences, zero filler, and the core constraint is front-loaded. Every clause carries weight.

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 navigation/mutation tool with no annotations and no output schema, the description leaves gaps: no mention of what happens to the current tab state, waiting/timeout behavior, or whether content is returned. Adequate but thin given the tool's complexity.

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

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

Schema coverage is 75%, with url, tab_id, and timeout already documented. The description reinforces the new_tab semantics ('create one only with new_tab=true'), which the schema encodes only structurally via oneOf, but adds little beyond the schema's own constraint language.

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 (navigate) and resource (a tab), plus the create path conditioned on new_tab=true. It partially differentiates from the observe sibling via 'No hidden observe', though the phrasing is terse and assumes familiarity with the observe/act/goto trio.

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 clause 'create one only with new_tab=true' implies when the create path applies, and 'No hidden observe' hints at a contrast with observe. However, no explicit when-to-use vs alternatives (observe, act, list_tabs) is given, leaving selection to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: listing does not select or focus a tab, i.e. it is side-effect free. However, it says nothing about ordering, scope (current window vs all windows), or whether the list can change between calls, leaving behavioral gaps for a no-annotation 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 that states the action, the returned data, and the key non-side-effect guarantee with zero filler. 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 simple enumeration tool with no output schema, the description covers the essentials: what is returned and that focus is unchanged. It is slightly short on return ordering and scope (which tabs are included), which an agent might want before relying on the IDs.

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?

Only one optional parameter exists and schema description coverage is 100%, so the timeout semantics (phase timeout, download 120000) are already fully documented in the schema. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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

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

The description gives a specific verb ('List') and resource ('tabs') and names the returned fields (stable page-target IDs, titles, URLs), so the agent knows exactly what it produces. It implicitly separates itself from a focus/select action, but never names a sibling such as observe or goto, so differentiation is contextual 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?

There is no statement of when to use this tool versus observe, goto, or act, and no prerequisites or exclusions are given. The only hint is the behavioral contrast ('without selecting/focusing a tab'), which implies the use case but never instructs 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?

No annotations are provided, so the description carries the full burden. It discloses one genuinely useful trait, 'No field values' (i.e. form values are excluded from output), plus cursor continuation, but says nothing about read-only semantics, side effects, error behavior, or output shape. Two facts do not cover a full behavioral profile.

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 and front-loads the return contents before the pagination hint, with no filler sentences. However, the compressed semicolon phrasing is ambiguous rather than efficient, and brevity here comes at the cost of 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?

With no output schema and no annotations, the description must explain what comes back; it only partially does so ('content, links and controls with exact refs', 'No field values') and omits pagination mechanics, cursor semantics, and the meaning of timeout/max_bytes. Inadequate for a 4-parameter browser 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 50% (cursor and max_bytes are undocumented). Worse, the description refers to 'next_cursor' while the actual parameter is named 'cursor', which could mislead an agent, and it explains nothing about max_bytes or cursor format/size limits.

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 resources returned (content, links, controls) and the ref mechanism, so an agent can infer this reads page structure. But it opens with a noun phrase rather than a verb+resource statement, and it never distinguishes itself from siblings like screenshot or act. Purpose is inferable but vague.

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

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

There is no explicit when-to-use guidance and no named alternative among list_tabs, goto, act, download, screenshot, or scroll. The only usage hint is 'continue all streams using next_cursor', which implies pagination continuation but leaves the primary selection condition unstated.

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

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

With no annotations, the description carries the full burden and does disclose output type (PNG ImageContent + metadata), the optional output file, and hard limits (6M pixels, 8192px/side, 4 MiB). It omits permission/auth requirements, whether the write of an output file is reversible, and pagination/streaming behavior, so disclosure is partial.

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

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

Two dense sentences, front-loaded with the output artifact before the scope exclusion and limits. Every clause carries information, though the telegraphic phrasing is borderline cryptic rather than genuinely concise-and-clear.

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

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

For a 6-param, no-annotation, no-output-schema tool, the description covers the return artifact and size limits but leaves the three undocumented boolean params and permission/behavioral context unexplained. It is adequate but has clear gaps for correct invocation.

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

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

Schema coverage is 50% and three params (mkdir, full_page, overwrite) have no schema descriptions. "Optional safe output file" loosely gestures at output/mkdir/overwrite, but full_page and overwrite behavior are never explained, so the description only marginally compensates.

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

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

The description states a concrete verb+resource ("Return actual PNG ImageContent and metadata") and scopes itself with "No focus/resize/scroll," which implicitly separates it from act/scroll siblings. It is clear what the tool produces, though it never names a sibling tool 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?

"No focus/resize/scroll" gives a when-not-to-use boundary, implying those interactions live in other tools. However, it does not say when to prefer screenshot over observe or how it relates to goto/list_tabs, leaving usage mostly implied.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: units are CSS pixels, it reports before/after movement, it does not guarantee lazy-load completeness, and it only works on the main document. However, it omits whether the call blocks, how the movement report is shaped, and any timeout/permission 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?

Three terse clauses with no filler, and the primary scope constraint (main-document) leads. The telegraphic style is efficient but borders on under-specified fragments.

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

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

For a 4-param tool with no annotations and no output schema, the description covers scope, units, and rough return semantics, which is decent. It still leaves the shape of the 'before/after movement' report and timeout behavior unaddressed, so it is adequate but not complete.

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

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

Schema coverage is 50%, with tab_id and timeout documented in-schema while amount and direction are bare. The description's 'CSS pixels' clause usefully clarifies the unit for the amount parameter, but it adds nothing for direction and leaves amount's range/semantics largely 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 conveys that this performs a wheel/scroll input on the main document, but the phrasing 'One main-document native wheel input' is cryptic and never states a clean verb+resource like 'scroll the page'. It does implicitly separate itself from inner-pane scrolling, giving partial sibling differentiation against act/observe/screenshot.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as act or observe for interacting with the page. The 'Inner panes unsupported' clause implies a scope exclusion but is not framed as usage guidance.

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