agbrowser

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

Annotations already declare the safety profile (not read-only, not destructive, not idempotent), so the bar is lower, and the description still adds meaningful behavior: steps runs up to 20 actions, stops at the first error, and returns one final diff; the default post-action view is a diff. It omits auth/secret handling nuance and any error-shape detail, keeping it below a 5.

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

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

Nearly every clause carries operational information — nothing is filler. Structure is weaker: it is one long run-on string with no line breaks, and it front-loads an upload edge case before the core 'what/when' framing, forcing the agent to scan past it to find the action list.

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 dispatch tool the coverage is decent but has holes: cookies, storage, and emulate are listed with zero explanation of what they do or expect, and close_session appears in the enum while a sibling close_session tool also exists — an ambiguity the description never resolves. With no output schema, the description should say more about what cookies/storage return.

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

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

Schema coverage is already 88%, so baseline would be 3, but the description earns more by binding parameters to each kind: type takes ref+value, press takes value=key, select takes ref+values, drag takes ref as source with args.to or args.to_target, and upload specifies the exact args.files=[{name,text|base64}] shape. That is genuinely additive for the free-form nested args object.

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 ('Act on the page') and then enumerates the full action vocabulary (click, type, drag, upload, dialog, steps), which makes the tool's scope unambiguous. It doesn't explicitly differentiate itself from siblings like evaluate, navigate, or extract, so an agent must infer that act is the interaction layer versus those tools.

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

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

There is real situational guidance embedded — 'for yes-flows first value=policy... then repeat the click', 'for a drop area without a ref use args.to_target', 'draggable elements are marked in the snapshot'. But there is no explicit statement of when to choose act over evaluate/navigate/snapshot, and no exclusions or preconditions (e.g. session must exist 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?

Beyond the annotations (which only declare not-read-only, not-idempotent, not-destructive), the description discloses the crucial consequence: the session ends and no further output is visible, including whether an answer already sent survives. It does not cover error behavior or what happens on a second call, which is why it is not 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?

Two short sentences, front-loaded with the most decision-relevant word ('Optional') and then the sequencing rule. Nothing is padded or repeated.

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

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

For a terminal, two-parameter tool with no output schema, the description covers optionality, required ordering, and the consequence of closing — enough to call it correctly. Minor gaps remain around failure modes (invalid or expired secret) and repeat 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 100% — both session_id and secret are documented as coming from create_session — so the schema already carries parameter meaning. The description adds no additional parameter semantics, which is the expected baseline here.

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

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

The description plainly states that calling this tool ends the session, and that no further output will follow — a specific verb-effect pair an agent can act on. It does not explicitly name sibling tools, but the terminal nature distinguishes it from create_session/extend_session/get_session by implication.

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

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

It gives real selection guidance: the call is optional because idle sessions self-terminate, and it should only be invoked after the final answer has been delivered. It stops short of explicit 'do not call in situation X' exclusions or naming a sibling, but the when-to-use condition is unambiguous.

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

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

Annotations only declare it as non-read-only, non-idempotent, non-destructive; the description adds substantial context beyond them — the two-phase paid handshake, the need to retain session_id and secret, the required polling for an active state, and the warning that page content is untrusted data. It stops short of stating what happens on payment failure, whether a quote expires, or the cost/refund path, which is the remaining gap for a paid mutation.

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

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

Four short sentences, front-loaded with the purchase action and options, followed by the payment protocol, credential-retention warning, and the safety note. Every sentence carries a distinct instruction; nothing is repeated filler.

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

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

With no output schema, the description does tell the agent what comes back (session_id and secret) and what to do with it (keep it, poll get_session). What is missing is any indication of the quote's shape or cost and the failure/expiry behavior, which for a paid provisioning tool leaves a small but 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 only 43%, and the description only reinforces duration options, the honest default, and the _meta payment carrier (which is not even listed in the schema properties — genuinely useful added meaning). It says nothing about locale, timezone, viewport_width/height, or start_url beyond the schema's own one-liners, so it does not fully 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 ('Buy a browser session') plus the concrete options ('10m, 30m or 60m'), which immediately distinguishes it from get_session, extend_session and close_session. An agent knows this is the provisioning/purchase step of the lifecycle, not a read or a mutation of an existing session.

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 call sequence: first without payment for the x402 quote, then again with the signed payment in _meta, then poll get_session until state is active before browsing. It names the sibling to use next and the precondition that must hold before any other tool (navigate, act) is safe to call.

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

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

Adds real constraints beyond the annotations: a 5-second timeout, a 64 KiB return cap, and the crypto.subtle limitation on http pages with the workaround (downloads give sha256). The annotations declare readOnlyHint=false and destructiveHint=false, consistent with arbitrary JS execution that may mutate, and the description's 'not for clicking' framing reinforces the intent. It does not state what permissions the script runs under or how errors surface.

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?

Roughly 25 words carrying purpose, usage boundary, return type, timeout, size cap, and a platform caveat. Front-loaded with the action and result, with constraints after – nothing wasted and 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 4-parameter arbitrary-execution tool with no output schema, the description covers the return type, runtime limits, and a known platform restriction. It leaves open script sandboxing and error behavior, which an agent might want before running a script that fails or times out.

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 all four parameters are documented in the schema, including that `ref` is bound to `el` and that `script` is an expression or a function body with await allowed. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a concrete verb and resource ('Run JavaScript in the page') and immediately pins down the return shape ('returns JSON'). The clause 'For data the snapshot lacks, not for clicking' distinguishes it from both `snapshot` and `act` without requiring the agent to open 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 inclusion ('for data the snapshot lacks') and exclusion ('not for clicking'), which routes the agent toward `snapshot`/`extract` for structured reads and `act` for interaction. It does not name `extract` as the alternative for bulk data extraction, so routing against that sibling is left implicit.

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?

The annotations already declare this is a non-read-only, non-idempotent mutation. The description adds meaningful context beyond that: it is a paid operation, uses stablecoins, follows the create_session quote/payment flow, and is capped by max_expires_at.

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

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

The description is a single front-loaded sentence with no filler. It communicates the paid extension action and the relevant constraints efficiently.

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 paid mutation with three required parameters and no output schema, important details are missing: secret semantics, session_id format/ownership expectations, and what a successful payment/extension returns. The description is adequate but not complete enough for an agent to call this confidently without inspecting the schema.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It mentions the duration values, but this only mirrors the enum and leaves secret and session_id undocumented, including their authentication and session-ownership roles.

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 uses a specific verb and resource: "Pay for another 10m, 30m or 60m on a session you own." The phrase "another" clearly distinguishes it from create_session, while "up to max_expires_at" scopes the operation.

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 states the prerequisite that the session must be owned and gives the upper bound via max_expires_at. It also points to the create_session quote/payment flow, though it does not explicitly say when to choose extension versus creating a new session.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds 'without acting' consistency and a note that find uses regex/args.queries with matching refs, but says nothing about result shape, pagination, or limits per kind.

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

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

It is front-loaded with the key idea and contains no filler, but the bulk is a single sprawling sentence with parenthetical asides, making it hard to scan for the relevant kind.

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 twelve kinds and a nested args object and no output schema, an agent can pick a kind but cannot tell what each returns or how args interacts with each kind. Adequate to start, but incomplete for correct invocation across modes.

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

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

Schema coverage is 83%, so baseline is 3. The description adds real meaning beyond the schema: find's query is a regex (with an example), args.queries can provide multiple patterns, matching elements come with refs, and the query field also filters links.

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 opening 'Get data without acting' states a specific verb and scope and implicitly contrasts with the sibling 'act' tool. The enumerated kinds make the resource concrete, though the sentence is a dense list rather than a crisp purpose statement.

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?

'Without acting' implies when to use this over 'act', and it usefully states 'there is no separate find tool', routing that query here. But it gives no guidance versus other read siblings like snapshot or evaluate, and no exclusions or prerequisites beyond required session fields.

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?

Adds real behavior beyond the annotations: rate limiting ("a few messages an hour"), no auth or payment required ("no payment, no account"), and human review ("A person reads it"). The annotations already signal this is a non-destructive write, so the remaining gap is what happens on send/failure (confirmation, rejection when throttled), which is not covered.

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

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

Four short sentences, front-loaded with the cost/friction answer ("Free.") and then the action. Every clause carries information: purpose, examples, human review, cost, auth, rate limit.

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 one-shot write with annotations and 75% schema coverage and no output schema, the description covers what to send, privacy constraints, cost, auth and throttling. Only the post-send outcome (acknowledgement or throttle error) is unaddressed, which is a minor 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 75%, so the schema already documents route, contact and message, and both enums are self-describing. The description's "a bug, an idea or a thanks" and "no secrets or private data" loosely mirror the kind enum and message constraint but add no new semantics. Baseline 3 applies.

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

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

States a concrete verb (tell the people who run the service) plus the resource (feedback: bug, idea, thanks), so an agent immediately knows this is a channel to the operators. None of the sibling tools (navigate, extract, create_session, etc.) overlap, so no disambiguation is owed.

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?

"what worked, what failed or what you miss" plus the bug/idea/thanks framing gives clear conditions for use, and it notes there is no alternative path needed. It stops short of stating when NOT to use it (e.g. don't use this for reporting tool errors mid-task versus user requests), so it is clear context without explicit exclusions.

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

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

With annotations declaring readOnlyHint=true, the description adds genuinely non-obvious context: the call has the side effect of keeping the session alive, which is not conveyed by any structured field. Returned content ('time left, usage, limits') is also sketched, though format and units are absent.

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

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

Two fragments, zero waste, but the telegraphic style omits the verb and connective logic that would make the sentence parseable on first read. It is brief without being well-structured.

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

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

For a two-required-parameter read tool with a fully described schema and safety annotations, the description covers the essential unknowns: what comes back and the keep-alive side effect. Only error/expiry behavior is missing, which is minor given no output schema and a simple input surface.

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 both session_id and secret are already documented in the schema. The description adds nothing about the parameters (e.g., what happens with an expired secret), so baseline 3 applies.

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

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

The description names the payload ('Time left, usage, limits') but never gives a verb, so it's unclear whether it retrieves status, refreshes it, or both. It also does not distinguish itself from siblings like extend_session or close_session, which an agent could easily confuse with a session-keeping-alive call.

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 call this versus extend_session (which presumably also affects session lifetime) or close_session. The phrase 'keeps the session alive' hints at a heartbeat usage, but the agent must infer it rather than being told.

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?

Beyond the annotations, the description discloses the return shape (full snapshot vs. outline), the escalation path for large pages, the wait-related latency tradeoff, and a security caveat that page text is untrusted data. The annotations already cover the mutation/safety profile (readOnlyHint=false, destructiveHint=false), so this description is adding genuinely useful 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?

Four telegraphic sentences, zero preamble, with the primary action front-loaded and the routing/constraint information following. The compressed phrasing ("wait=load or idle for slow pages") is dense but unambiguous.

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

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

With no output schema, the description correctly takes on the job of describing what comes back (snapshot vs. outline) and how to continue. The only omission is what happens when no tab is open or how the "current tab" relates to the tabs sibling, which forces a small inference.

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%, which sets a baseline of 3, and the description still adds meaning: it constrains url to public http(s) and explains when to pick wait=load or idle. It does not mention the snapshot parameter or the session_id/secret prerequisites in prose, but those are fully documented in the schema.

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

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

"Open a URL in the current tab" gives a specific verb, resource, and scope, and the sentence about small vs. big pages distinguishes this tool from the snapshot/find/read siblings that it feeds into. An agent can tell what this does and where it sits in the workflow without opening the schema.

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

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

It routes the agent conditionally: small pages yield a full snapshot, big pages yield an outline and require find, read, or snapshot scope, and wait=load or idle is the answer for slow pages. It also states the domain restriction (public http(s) only). Lacks an explicit "don't use this when..." exclusion, so it stops just short of a 5.

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

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

Annotations already declare readOnlyHint/non-destructive, so safety is covered. The description adds genuinely useful context beyond that — the token cost and the cheaper alternative — but says nothing about output size/token magnitude, default viewport behavior, or latency.

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 capability and followed by the cost caveat. Zero filler; every clause carries information.

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

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

For a 7-parameter tool with no output schema, the description covers the mode selection and the main decision driver (cost vs. snapshot). Minor gaps remain around default output type/size and what pdf mode returns, but nothing critical 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 86%, so the schema already explains each parameter. The description adds only a loose mapping of the capture modes; it omits pdf, full_res, and the default viewport behavior, so it adds little beyond the structured fields.

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 (JPEG screenshot) and enumerates the capture modes (viewport, ref, region, full page), which lets an agent distinguish it from snapshot. It stops short of mapping modes to the pdf/ref/region parameters, but the core purpose is unambiguous.

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

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

Explicitly routes the agent to the cheaper alternative: 'snapshot is cheaper', which gives a clear when-to-prefer condition. It doesn't say when a screenshot is actually required over snapshot (e.g. visual rendering or PDF output), leaving that inference to 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?

Annotations already declare readOnly and non-destructive, so the description's job is to add context, which it does: ref lifecycle ('Refs stay valid while the element exists') and diff semantics are genuinely useful. It omits truncation behavior, even though the cursor parameter implies the tree can be cut off.

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

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

Four compact clauses, front-loaded with the output description, then ref semantics, drag marking, and diff mode. No filler sentences and every clause carries information.

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

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

With no output schema, the description must describe the return value and does so well (compact tree, refs, drag markers). Truncation/cursor continuation is left entirely to the schema, a minor gap given the 20000-char cap.

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 every parameter including mode, scope, cursor and max_chars is already documented. The description only reinforces mode=diff and the ref convention, adding little beyond the schema, which is the expected baseline 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 resource and output shape: 'Current page as a compact tree' with interactive elements tagged ref=eN. It clearly conveys what an agent gets back, but never names siblings like screenshot or extract to sharpen the boundary between them.

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

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

Usage is only implied: the ref=eN scheme tells the agent this is the tool to call before click/type/select, and mode=diff hints at incremental polling. There is no explicit 'use this when X, use screenshot/extract instead when Y' 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?

Annotations declare the safety profile (not read-only, not destructive, not idempotent), and the description adds behavior beyond that: a hard cap of 5 tabs and the popup-never-auto-selected rule. Worth noting: a tool whose op enum includes 'close' sits somewhat awkwardly with destructiveHint=false, though the description itself doesn't contradict the annotation.

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, capabilities front-loaded, the popup caveat second. No filler and nothing that could be cut without losing meaning.

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

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

No output schema exists, and the description implies that 'list' yields tab identifiers suitable for 'select', which is adequate for a 4-op multiplexed tool. It does not say what a close returns or whether closing the last tab is an error, leaving a small 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 80%, so op/tab/url/session_id/secret are already documented in structured fields. The description adds only the 'max 5' bound and the list-then-select ordering; it says nothing extra about tab id format, url semantics, or what happens when the 5-tab cap is exceeded.

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

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

Opens with a concrete verb set (list, open, switch, close) bound to a specific resource (tabs), and the max-5 constraint scopes the resource. It doesn't explicitly distinguish itself from navigate/act, which an agent might reasonably confuse with 'open' or 'switch', so it falls short of the 5 bar.

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

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

Gives an actionable sequencing rule: 'Popups open as new tabs but are not selected: list, then select.' That is real when-to-do-what guidance an agent can follow. No exclusions or alternatives among siblings (act vs navigate vs tabs) 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?

Annotations already declare destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the blocking semantics of the conditions, but omits two behaviors an agent would care about: that the call produces a page snapshot afterward (visible only in the snapshot param as 'page view after the action') and what the tool does when the timeout expires — error versus silent return.

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 resolution conditions before the comparative advice. No filler or restated name/title.

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 11-parameter tool with no output schema, the description leaves the agent guessing about the return payload (snapshot diff default), timeout failure behavior, and how multiple condition params interact if more than one is supplied. Adequate to invoke, 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 64%, so baseline is 3. The description does group the condition parameters (text/text_gone/ref/selector/url) and implies exclusivity via 'use one text condition', which is real meaning beyond the schema; however it never mentions timeout, snapshot, or secret, and 'the URL changes' is looser than the actual url_contains substring 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?

States a specific verb (wait) with the exact conditions it resolves on: text appearing, text_gone disappearing, ref/selector becoming visible, or URL change. The contrast with 'fixed delays' carves out a clear niche against the ms parameter and against naive polling, though no sibling tool (e.g. act, snapshot) is named as an alternative.

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?

'Use one text condition' is an explicit invocation constraint, and 'Better than fixed delays' tells the agent when to prefer this over a plain ms sleep. It stops short of stating when-not-to-use it (e.g. when act already auto-waits) or what happens on timeout expiry.

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