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 is nearly silent: it does not say whether the click waits for navigation, scrolls the element into view, errors on a stale/detached ref, or what side effects a click may trigger. For an action tool with real side effects this is a substantial gap.

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

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

A single short sentence with the key addressing mechanism front-loaded and no filler. It is efficient, though the brevity comes at the cost of substance rather than reflecting genuine completeness.

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

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

For a 4-parameter action tool with no annotations and no output schema, the description omits the behaviours an agent most needs: wait/navigation semantics, failure modes on invalid refs, and the meaning of button and double. It is far too thin for 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 only 50%: ref and snapshot are described in the schema, but button (left/right/middle) and double are not documented anywhere. The description adds no meaning to any parameter, so it fails to compensate for the undocumented half.

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 (click) and object (an element, addressed by its snapshot ref), so the action is unambiguous. It does not, however, distinguish itself from near-neighbours such as hover, press, or evaluate, so the agent gets no explicit routing cue 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?

"By its snapshot ref" implies the prerequisite that a snapshot must exist first and that refs are the addressing mechanism, which is useful implied context. There is no explicit when-to-use/when-not guidance and no mention of when to prefer type, press, hover, or evaluate instead.

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

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

No annotations are provided, so the description carries the burden and does so well: it discloses the default behavior without the tool (alerts accepted, confirms/prompts dismissed) and that results report every dialog. It stops short of explaining what 'accept' means for beforeunload (navigate away) or prompting edge cases.

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

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

Two sentences, front-loaded with the core purpose and ordering constraint, with the default-behavior consequence second. No wasted 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?

No annotations and no output schema, so the description must stand alone; it covers purpose, ordering, and defaults well. The remaining gap is per-dialog-type semantics of the action parameter, which an agent may still need to infer.

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% — promptText is documented in the schema, action has an enum but no description. The description contextualizes prompt() by naming it, but never clarifies how accept/dismiss map onto each dialog type or when promptText is required, so it 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?

States a specific verb ('Decide how to answer') and resource ('the next JavaScript dialog'), and enumerates the dialog types (confirm, prompt, beforeunload) it governs. An agent can distinguish this from navigation/click/type siblings without opening the schema.

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

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

Gives a clear timing rule — call it 'before the action that triggers it' — which is the key selection condition for this tool. It also implies when it is not needed by describing the default handling, but it does not name an explicit alternative tool or exclusion.

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

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

With no annotations, the description carries the full burden. It discloses the execution context (active tab) and return type (JSON), but says nothing about arbitrary code execution, potential DOM side effects, permissions, CSP restrictions, or whether the expression can mutate page state, which matters greatly for an eval-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 compact sentences with the core capability front-loaded and the differentiation clause second. No filler and nothing redundant.

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

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

For a one-parameter tool with full schema coverage and no output schema, explaining the JSON return value is adequate. The remaining gap is behavioral: the risks and side effects of running arbitrary JS in a live tab are left unstated.

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

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

There is a single parameter with 100% schema description coverage, and the schema already supplies an example. The description adds no further syntax or format guidance beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Run a JavaScript expression) and resource (the active tab) plus the return type (JSON result). The clause 'For reading data the other tools do not expose' distinguishes it from siblings like read and snapshot.

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

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

The phrase 'data the other tools do not expose' implies it is a fallback for cases the read/snapshot tools cannot cover, which gives useful context. However, it names no specific alternative tool and gives no explicit when-not-to-use or precondition guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not say what happens at a history boundary (no forward entry available), whether this is a state mutation of the tab, or what the snapshot parameter actually causes — the schema mentions a 'fresh snapshot' but the description never connects to it.

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

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

A single short sentence with the core action front-loaded and zero filler. It is efficient, though its brevity is part of why behavioral gaps remain.

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

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

For a simple two-parameter navigation tool with no output schema and no annotations, this is minimally adequate. It leaves open boundary behavior, the effect of snapshot, and whether the action can fail, all of which an agent would want before calling.

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%, but the undocumented parameter (direction) is a two-value enum whose meaning is self-evident, and snapshot is documented in the schema itself. The description's 'back or forward' phrase mirrors the enum without adding format or edge-case detail, so it neither compensates nor detracts.

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 pair (go back/forward) and the resource (the active tab's history), which is enough to separate it from navigate, which presumably targets a URL rather than an existing history entry. It stops short of naming those siblings explicitly, so it is clear but not maximally differentiating.

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

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

There is no guidance on when to use this versus navigate, tabs, or read, nor any mention of prerequisites such as needing an existing history entry. Usage must be inferred entirely from the tool name and the word 'history'.

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

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

No annotations are provided, so the description carries the full burden. It discloses the hover action and its UI effect, but omits operational details such as whether it scrolls the element into view, waits for the menu to appear, or what happens on failure.

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

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

One short, front-loaded sentence with no filler. The action and effect are stated immediately, and every word 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 interaction tool with no annotations and no output schema, the description covers the core action and effect. However, it lacks enough behavioral context about waiting, ref sourcing, and failure behavior to be fully 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%: snapshot is documented in the schema, while ref has no schema description. The phrase 'by ref' partially compensates by indicating that ref is an element reference, but adds little syntax or validation 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 ('Move the mouse over'), the target ('an element by ref'), and the outcome ('opens hover menus, tooltips'). This distinguishes it from sibling click/type/select tools without needing the schema.

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

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

The parenthetical effect implies the use case—triggering hover menus or tooltips—but gives no explicit when-to-use guidance versus alternatives like click, nor any exclusions. Usage is implied rather than stated.

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

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

With no annotations, the description must carry the full behavioral burden. It does not disclose whether navigation waits for page load, what happens to the current page state, error handling, or any permissions required. Only the scope (active tab, this pod) 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 no wasted words. It is appropriately concise for a simple action, though the brevity contributes to the behavioral gaps noted elsewhere.

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

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

For a simple navigation tool with a fully documented two-parameter schema and no output schema, the description covers the core action and scope. However, it lacks behavioral context that an agent might need, such as page-load waiting or state changes. Minimal viable.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters ('url' and 'snapshot'). The description adds no additional parameter meaning beyond what the schema provides. 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 (open) and resource (URL), and scopes it to the active tab of the current pod. It does not explicitly differentiate from siblings like 'tabs' or 'evaluate', but the action is clear enough for an agent to identify.

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 alternatives such as 'evaluate' for scripted navigation or 'tabs' for switching. Usage is only implied by the tool name and description.

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 usefully discloses the pod's isolation model — a private browser window in a shared logged-in Chrome where other agents' pods and the user's own tabs are never visible — which is key scope context. It leaves the read-only nature implicit ('Show') and omits any auth or rate-limit details, but for a zero-parameter status tool this is largely sufficient.

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

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

Two sentences, front-loaded with the core action and return, followed by essential isolation context. Every sentence earns its place with no redundancy.

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

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

Given the tool's simplicity (zero parameters, no output schema, no annotations), the description supplies what is needed: the resource, the returned fields (label, owned tabs), and the visibility boundaries. A consuming agent has enough 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?

The tool takes zero parameters, so there are no parameter semantics to document; the baseline for zero-parameter tools is 4. The description appropriately avoids discussing inputs and focuses on the output/status information.

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 ('Show') and resource ('this agent's pod'), and specifies the payload ('its label and the tabs it owns'). It implicitly distinguishes from the generic 'tabs' sibling by scoping to owned tabs, but does not name or contrast with the closely related 'pod_window' sibling, 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 implies usage by describing what the tool returns, but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. No sibling like pod_window is referenced as an alternative, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the effect of each state and implies the user must see the window for login/CAPTCHA, but it says nothing about whether showing steals focus, whether minimize persists across calls, or how either state affects other pod tools (click/type/screenshot).

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 pairs the action with the two states, then appends the usage examples. No filler, though the trailing example clause makes it slightly run-on.

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 toggle with no output schema, the description covers purpose, both states, and the motivating scenarios, which is enough to call it correctly. Minor gaps around interaction side effects remain.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning, and it does: 'show' and 'minimize it to the taskbar' map directly onto the two enum values with their effects. It stops short of clarifying defaults or state persistence, but the enum is fully explained.

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

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

States two specific verbs on a specific resource: show this pod's window or minimize it to the taskbar. The name 'pod_window' is vague on its own, but the description resolves it and clearly separates this from capture tools like screenshot or navigation tools like navigate/tabs.

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

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

Gives concrete triggering conditions ('when the user asks to watch', 'when you need them to log in or solve a CAPTCHA'), which is exactly the kind of situational guidance an agent needs. It does not, however, state when NOT to use it or name a sibling alternative (e.g., screenshot) for read-only inspection.

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, yet it says nothing about whether an element must be focused first, whether the press is dispatched to the active tab's focused element, or what happens on failure. The 'active tab' phrase gives only minimal scoping context.

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

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

A single efficient sentence with the core scope front-loaded and examples appended. Nothing is wasted, though it is quite thin for a tool with no annotation coverage.

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

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

For an input-action tool with zero annotations and no output schema, the description omits focus requirements, target element resolution, and error behavior. The absence of an output schema means return values needn't be explained, but the behavioral gaps remain.

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?

'snapshot' is documented in the schema, but 'key' has no schema description; the description supplies useful example values (Enter, Escape, ArrowDown, Control+A) that compensate partially. At 50% schema coverage the description adds value but does not fully describe key syntax or modifier combinations.

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

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

States a specific verb ('Press') and resource ('key or shortcut in the active tab'), with concrete examples (Enter, Escape, ArrowDown, Control+A). It implicitly distinguishes itself from 'type' (text entry) and 'click', though it never names those siblings explicitly.

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

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

No statement of when to use this versus the very similar 'type' tool, nor any prerequisites about focus or which element receives the event. Only the examples hint at intended usage.

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

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

With no annotations, the description carries the full burden. It discloses the return format (plain text) and the default scope (main content), which is useful, but says nothing about truncation via maxChars, permissions, or whether the read is purely side-effect-free.

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 the default scope in parentheses. No 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 read-only tool with no output schema or annotations, the description is adequate but thin. It does not explain that returned content is capped by maxChars (default 8000) or what the response structure looks like, leaving the agent to infer 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 description coverage is 100%, so both parameters are already documented. The phrase 'main content by default' adds meaning to the selector parameter's default behavior, but maxChars and its truncation effect are not elaborated. 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?

States a specific verb (read) and resource (visible text of the page), plus the default scope (main content) and output form (plain text). It is clear what the tool does, but it does not distinguish itself from overlapping siblings like snapshot or evaluate, which also surface 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 explicit when-to-use, when-not, or alternative routing. An agent must infer that this is for extracting page text rather than choosing between read, snapshot, evaluate, or screenshot on its own.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the output encoding (JPEG) and the capture scope (active tab, i.e. viewport), but says nothing about what is returned (bytes, path, base64), permissions, or how the 'fullPage' flag changes the capture region.

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

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

Two short sentences, zero filler, with the capability front-loaded and the disambiguation trailing. 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 single-parameter capture tool with no annotations or output schema, the description covers the essentials but leaves the lone parameter and the return value unexplained. Adequate as a minimum viable definition, 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?

There is one parameter with 0% schema description coverage, so the description must define it. 'fullPage' is never mentioned, and 'screenshot of the active tab' actually implies viewport-only capture, leaving the parameter's meaning and its effect on output size 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?

States a specific verb and resource ('Take a JPEG screenshot of the active tab') with the output format included, and explicitly distinguishes itself from the sibling 'snapshot' tool. An agent can separate this from the other seventeen tools without opening the schema.

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

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

Gives an explicit when-not and a named alternative: 'Prefer snapshot for reading; use this for visual checks.' The selection rule is unambiguous and routes the agent to the correct sibling.

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 disclose that scrolling may trigger lazy-loading/infinite-scroll state changes, whether the action is read-only, or how the ref/screens/direction parameters interact when both are supplied. Only the two basic modes are described.

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

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

A single front-loaded sentence with no filler; both clauses earn their place by naming the two operating modes. Slightly too terse given the parameter interactions it omits.

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 four parameters, 75% schema coverage, no annotations, no output schema and no default direction documented, the description leaves meaningful gaps: precedence of ref vs screens/direction, default scroll direction, and what state changes scrolling triggers.

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%, so the schema already documents ref, screens and snapshot; the description reinforces only the ref mode. It adds nothing about direction (enum undirected in the schema) or snapshot, leaving schema baseline at 3.

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 two resources/modes: page-by-screens and element-into-view-by-ref. The two modes are clearly separated, but it never distinguishes itself from the many other browser siblings 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?

Usage is only implied: pass ref to bring an element into view, otherwise scroll by screens. There is no explicit when-to-use, no precedence rule (does ref override screens/direction?), and no mention of when snapshot=true is desirable.

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 disclose side effects, whether selection triggers change events, what prerequisites exist for the ref, or what happens after selection, beyond the optional snapshot parameter in the schema.

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

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

A single efficient sentence, front-loaded with the verb and target element. Every phrase adds necessary meaning without 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?

For a browser automation action with no annotations and no output schema, the description omits important context such as where ref comes from, what occurs after selection, and how multi-select is handled. Siblings like snapshot and click imply a richer context that the description does not address.

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 33%, with just the snapshot parameter documented in the schema. The description clarifies that values match option value or label and that multiple options are possible, but ref is left unexplained beyond its name, so it only partially compensates for the low 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?

States a specific verb ('Choose') and resource ('option(s) in a <select> element'), plus the matching mechanism ('by ref, matching option value or label'). An agent can distinguish this from siblings like click, type, or evaluate without opening the schema.

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

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

Provides no explicit when-to-use guidance, prerequisites, or conditions for choosing this tool over alternatives such as click, type, or evaluate. Usage is only implied by the mention of a select element.

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

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

No annotations are provided, so the description carries the full burden, and it delivers the two most operationally important traits: the output is a compact text view with [e12]-style refs, and those refs are invalidated by any subsequent snapshot. It omits other traits such as whether the view is truncated or scroll-relative, which is why it falls short of a 5.

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

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

Three sentences, no padding, and the output shape is front-loaded ahead of the ref-usage and expiry rules. Every sentence earns its place by adding a distinct operational fact.

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

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

For a single-optional-parameter read tool with no output schema, it covers the return shape, the ref format, the downstream tools, and the ref lifecycle. It leaves one gap: behavior when maxElements truncates the view, and no signal about scroll position or frames.

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 maxElements parameter and its default is documented there ('Default 150.'). The description adds no meaning about how the cap affects output or what happens when elements are omitted, so the baseline 3 applies.

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

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

States a specific verb and resource: a 'compact text view of the active tab' returning title, URL, headings and visible interactive elements. This cleanly distinguishes it from siblings like read (content extraction), screenshot (visual), and evaluate (scripting).

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 forward: the emitted refs are meant for click, type, select and hover, and it warns that refs expire when a new snapshot is taken. It does not say when to prefer snapshot over read, evaluate, or pod_status, so the alternative-selection guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden, and it falls short: it never states whether closing a tab is destructive, what happens when the last tab is closed, whether switching requires an index, or any permission/auth requirements. 'Optionally at a URL' is the only behavioral nuance offered.

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

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

A single front-loaded sentence that enumerates the operations efficiently with no filler. It is slightly dense (a colon-list of four clauses in one line) but every clause earns its place by naming a distinct action.

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 stateful tool that can create and destroy tabs, with no annotations and no output schema, the description omits what 'list' returns, what 'new' returns, and how indices behave after a close. An agent would need to guess at return shape and post-close index semantics, leaving a real gap.

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

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

Schema coverage is 67% — url and index already have descriptions in the schema, and the action enum is self-documenting. The description's 'optionally at a URL' echoes the schema's url semantics without adding format or constraint detail, so the schema remains the primary source. 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?

The description gives a specific verb (manage) and resource (tabs) and enumerates the four supported operations — list, new, select, close — which map to the action enum. The 'of this pod only' scoping is a useful qualifier, but it never distinguishes this tool from the sibling pod_window, which an agent could reasonably confuse for tab handling.

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?

Listing the four actions gives implied usage for each, and 'of this pod only' sets a scope boundary. However, there is no explicit when-to-use guidance and no alternatives named — notably nothing tells the agent when to reach for pod_window versus tabs, or that the sibling 'select' is unrelated to the 'select' tab action 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?

With no annotations, the description carries the full burden. It usefully discloses that existing text is replaced unless append is true — a destructive-ish side effect not stated anywhere in the schema. However, it omits other behavior an agent needs: whether focus is required, what happens on an invalid ref, and how submit/snapshot interact.

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 pair with the core action front-loaded and the replacement caveat immediately after — no filler. It could be slightly expanded without waste, but nothing present is redundant.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the main action and the append toggle but leaves the critical ref-provenance question unanswered and does not describe the return value or error behavior. Adequate but with clear gaps.

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

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

Schema coverage is 40%: only submit and snapshot carry descriptions; ref, text, and append are bare. The description partially compensates by explaining append's replace-vs-append semantics, but it adds nothing about what ref refers to (an element reference, presumably from snapshot) or the format of text.

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

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

States a specific verb (type) and resource target (input, textarea, contenteditable element identified by ref), which lets an agent distinguish it from sibling tools like press or click. It does not explicitly name a sibling it competes with, but the target-element enumeration makes the scope clear.

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 alternatives such as press (for key events) or click (for activation), nor any prerequisites (e.g. that the element must exist and be focusable). The append clause is a behavioral detail, not usage routing.

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 says the tool waits, but does not disclose what happens on timeout (error vs. silent continuation), whether it blocks other interactions, what it returns, or how the snapshot parameter alters the result. These are significant omissions for a wait primitive.

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 waste. It communicates the two possible behaviors efficiently without repetition or filler.

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

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

For a tool with zero required parameters, no annotations, and no output schema, the description should clarify behavior when called with no arguments, the default timeout, what happens on failure, and what the snapshot option returns. It omits all of this, leaving the agent to infer core 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 67% (text has no description, seconds and snapshot do). The description adds meaning to 'text' and 'seconds' by framing them as the two wait modes, but it does not explain the snapshot parameter or add detail beyond the schema's own description for seconds. This is an adequate but incomplete mapping.

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 ('Wait') and two clear resources (text on the page, or a fixed time), so an agent immediately understands the tool's function. It does not name or differentiate from any sibling, but no sibling overlaps with waiting, so the lack of explicit differentiation is less critical.

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 the two waiting modes but gives no when-to-use context, prerequisites, or guidance on choosing between text-based and fixed-time waiting. There are no explicit alternatives mentioned, and no conditions such as 'use before interacting with dynamically loaded content' are provided.

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