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

With no annotations present, the description carries the full burden of behavioral disclosure. It does reveal the core behavioral pattern (sequential navigation, uniform JS expression per page), but it does not disclose that arbitrary JS execution can have side effects or mutate page state, nor what the tool returns for each URL. For a tool that runs JavaScript across multiple pages, that safety-relevant gap is notable.

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 with zero filler: the first fronts the action (what the tool does), the second delivers routing guidance (when and when-not). 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 moderate-complexity tool with fully documented parameters, the description covers purpose and usage completely. The remaining gaps are the return format (no output schema exists to fill it) and unstated side-effect potential of JS evaluation (no annotations exist either). These are meaningful but do not prevent an agent from invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description reinforces evaluate_per_page's semantics ('the same JS expression on each') but adds no new parameter-level detail beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb-resource-action combination: 'Visit several URLs in sequence and run the same JS expression on each.' It also explicitly distances itself from siblings by naming view_page/run_plan and stating what it is not for ('normal reading, clicking or form work'), making it impossible to confuse with the other browsing 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?

The description gives an explicit when-to-use condition ('controlled checks across known pages'), names the alternatives it replaces ('where view_page/run_plan would be too chatty'), and lists exclusions ('not for normal reading, clicking or form work'). An agent can make a correct routing decision with no additional 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 full behavioral disclosure. It states that the tool returns no refs and reads no text, and gives output constraints (WebP, 800px, <100KB). It does not explicitly say 'does not modify the page' but that is strongly implied by the screenshot nature; the disclosed constraints are sufficient for an agent to set expectations.

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 two sentences, front-loaded with the core definition and constraints, followed by usage guidance and sibling differentiation. Every word earns its place; no redundancy or fluff.

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 tool with two optional boolean parameters and no output schema, the description covers purpose, constraints, use cases, and key behavioral differences from view_page. A minor gap is that it doesn't explicitly describe the returned image data format, but the WebP and size details imply the output adequately.

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 'som' and 'full_page' have clear descriptions in the schema. The tool description does not add extra parameter-level detail, but since the schema already documents both parameters adequately, the baseline score of 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 opens with a precise definition: 'Pixel-level screenshot' with concrete format and size constraints (WebP, max 800px, <100KB). It further distinguishes itself from view_page by stating that it returns no refs and reads no text, making the tool's purpose unambiguous and clearly separated from its sibling.

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

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

Usage is explicitly scoped: 'Only for canvas or chart content without DOM text, pixel-level rendering or animation checks, or when the user explicitly asks for a screenshot.' It also names the alternative (view_page) for cases involving refs/text, giving the agent clear routing guidance.

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

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

With no annotations, the description carries the full transparency burden. It discloses that real CDP mouse events are dispatched, that a click opening a new tab is reported in the response, and that DOM diff results arrive with the next response unless wait_for_diff is set. These are significant behavioral details beyond 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?

Three sentences with no filler. The first sentence front-loads the tool's purpose and target options; the second and third cover event dispatch and async behavior. Every sentence adds value.

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

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

The description covers targeting modes, event behavior, new-tab reporting, and diff timing, which is substantial given the absence of annotations and output schema. It does not explicitly define precedence when multiple target parameters are supplied, though the schema's 'preferred' and 'fallback' labels mitigate that 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?

All six parameters are fully described in the schema, so the baseline is 3. The description adds useful cross-parameter semantics: it clarifies the relationship between x/y, explains that text targeting works without view_page, and highlights the wait_for_diff latency trade-off.

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 (Click) and enumerates the supported target strategies: ref, CSS selector, visible text, and viewport x/y for canvas/pixel-precise targets. This clearly distinguishes the tool from siblings like type, press_key, and scroll.

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

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

The description gives strong within-tool usage guidance: ref is preferred, selector is a fallback, text needs no view_page, and x/y is for canvas/pixel-precise targets. It does not explicitly contrast with sibling tools like type or fill_form, but the targeting guidance is clear enough to select the correct mode.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals the dual view/set behavior, what autoPromote actually does, and the important ordering constraint that profile changes should happen before browser interactions. It does not discuss persistence or side effects beyond what the schema already documents, but the description provides meaningful behavioral context rather than just restating the tool name.

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 only two sentences, yet it communicates the core operation, the no-parameter behavior, the autoPromote effect, and the profile timing constraint. Every clause earns its place with no filler or repetition.

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

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

Given the tool's moderate complexity, four optional parameters, and absence of an output schema, the description covers the essential cases: viewing defaults, applying suggestions, and setting a profile before browser interaction. It could be more explicit about what the returned defaults look like or how the defaults object relates to recurring parameters, but it is sufficient for an agent to invoke the tool correctly in the main scenarios.

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

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

The schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds extra meaning by explaining the zero-parameter call behavior and by specifying that profile must be set before browser interaction, which is not conveyed by the schema's parameter descriptions alone.

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

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

The description opens with a specific verb-resource pair, 'View or set session defaults,' and clarifies that it handles recurring parameters like tab and timeout. This distinguishes it clearly from the sibling browser-interaction tools, which act on pages or tabs rather than session-level configuration.

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 concrete usage conditions: calling with no parameters shows current defaults and auto-promote suggestions, setting autoPromote to true applies them, and profile must be set before any browser interaction. It does not explicitly name alternatives or state when not to use the tool, so it doesn't earn a 5, but the guidance is clear and actionable.

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

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

No annotations are present, so the description must carry the full disclosure burden. It does so by explicitly labeling the operation as 'Read' and prominently disclosing the optional destructive side effect of clearing the buffer. It could add more detail about buffer source or retention, but the key side effect is clearly exposed.

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 well-structured sentence packs the main action, the filtering options, and the optional side effect without wordiness. It is front-loaded with the most important information and every phrase 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?

The tool has only three optional parameters, no output schema, and no annotations, so the description adequately covers purpose, filters, and the clear flag. Minor gaps around return format and where the logs come from remain, but they are not critical for a tool this simple.

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 the baseline is 3. The description goes beyond the schema by explaining that 'level' and 'pattern' can be used together as filters ('and/or regex') and that 'clear' is an optional post-read action, which clarifies parameter relationships and intent.

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 ('collected browser console logs'), then adds filter behavior and an optional clearing side effect. This clearly distinguishes it from the other browser automation siblings by emphasizing a read-only diagnostic purpose.

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

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

The purpose is obvious: read logs, apply filters, optionally clear. It doesn't explicitly name alternatives or exclusion conditions, but the context is sufficient because this tool serves a unique diagnostic function among the sibling browser tools.

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

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

No annotations are present, so the description carries full responsibility. It discloses the kind of data returned and the scope of use, and the data-only framing implies a read-only operation. It doesn't explicitly state that no page mutation occurs or what happens when ref is omitted, but it is reasonably transparent for a snapshot-introspection 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 tightly packed sentences: the first lists the data categories and the cross-tool ref relationship; the second states the exclusive usage condition. No filler, no repetition, and key information is front-loaded.

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 no output schema, the description covers the nature of return data, the ref linkage to view_page, and the intended use case. A small gap is the unspecified default scope when ref is omitted, but the schema's 'subtree snapshot' partially addresses that. Overall, sufficient 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?

The schema already documents the only parameter (ref) at 100% coverage, so baseline is 3. The description adds genuinely useful context by noting 'refs match view_page', telling the agent that refs are shared with the sibling tool and clarifying how to populate the parameter. This exceeds the schema alone.

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 clearly states the tool's resource and function: it provides structured layout data including bounding boxes, computed styles, paint order, and colors. It explicitly distinguishes itself from view_page by naming the exact spatial questions it answers, so an agent can differentiate it from siblings without inspecting schemas.

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 explicitly says the tool is 'only for spatial questions view_page cannot answer' and provides concrete examples ('is A above B? what color?'). This is a clear when-to-use instruction and also implies when to prefer view_page, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden. It clearly discloses that the tool never triggers downloads and that the default call waits while list returns immediately. It could additionally describe what happens when no download is pending or what the return payload looks like, but the schema partially covers timeouts and settling.

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 with no filler: the first states the core purpose, the second explains the triggering mechanism, and the third shows the behavioral difference between modes. The most important information is front-loaded.

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

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

The tool has no output schema and no annotations, but the description plus the rich parameter schema gives the agent enough to call it correctly. It explains what the tool does, when to use it, and which mode to choose for waiting vs. listing, though an explicit note about the return format would make it 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 description coverage is 100%, with detailed descriptions for action, settle, and timeout, including defaults and enum meanings. The description adds a useful call-form example but not semantic information beyond what the schema already provides, so 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 states a specific verb and resource: 'Wait for pending downloads or list this session's downloaded files.' It also clearly distinguishes itself from triggering tools by saying 'this tool never triggers them,' which prevents confusion with click/navigate/file actions.

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 explicitly tells the agent when to use the tool: after a download link is clicked or a file URL is opened, and explains that downloads are triggered by user/browser actions, not by this tool. It also distinguishes the two modes: status waits, list returns immediately for polling.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals the low-level mechanism (native CDP mouse events), the interaction types it can drive, and its exclusions. It stops short of describing side effects like cursor movement or whether the action waits for animations to settle, but it is substantially transparent for a drag 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?

The description is compact but information-dense. The first sentence states the purpose and supported drag types; the second states exclusions and source/target options. Every clause adds value, though the long list of excluded frameworks is slightly verbose. Still, it is well front-loaded and efficient.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description covers the essential guidance: what it does, what it cannot do, and how to specify source and target. The 'steps' parameter is already documented in the schema. The only minor gap is that it does not mention what happens after the drag completes (e.g., waiting for resulting state), but overall it is sufficiently complete for an agent 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?

All 9 parameters have schema descriptions, so the schema already provides individual meaning. The description adds valuable higher-level semantics by grouping source parameters as 'from_ref/from_selector or from_x+from_y' and target parameters similarly, clarifying exclusive pairings that the schema alone does not express. This meaningfully helps an agent construct valid parameter 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?

The description opens with a specific verb and resource: 'Drag via native CDP mouse events.' It then enumerates concrete use cases (slider thumbs, resize handles, text selection, mouse-based reorder lists) and explicitly distinguishes itself from the HTML5 Drag&Drop API. This makes the tool's purpose unmistakable and clearly separates it from sibling input tools like click, type, and scroll.

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 explicitly states when NOT to use this tool ('NOT for the HTML5 Drag&Drop API') and names the alternative mechanism ('that needs Input.dispatchDragEvent'). It also lists the scenarios it DOES support, giving clear conditions for selection. No inference is required to decide whether this tool fits a given drag task.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers: it warns that scope is shared between calls, top-level declarations are wrapped in an IIFE, and if/else blocks may return undefined, recommending ternaries or explicit returns. This is meaningful execution behavior an agent needs to predict results. It omits error handling and return-format details, but the provided traps are valuable.

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 compact sentences carry high signal: the primary purpose, a curated list of good uses, and the critical behavioral caveats. Every sentence adds value, and the most important facts are front-loaded. It is appropriately concise for the complexity involved.

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 generic JS-evaluation tool with two simple parameters and no output schema, the description covers purpose, usage scope, and key execution quirks. Missing are default return behavior and error semantics, but the given detail is enough for most agent decisions. The tool is not so complex that every nuance needs explanation.

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%: both 'expression' and 'await_promise' have descriptive schema text. The description adds no parameter-level information, so it earns the baseline score of 3. No gaps in parameter understanding remain because the schema already explains them.

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 begins with a clear verb and resource: 'Run JavaScript in the page.' It then enumerates specific good-use categories (computation, style mutations, shadow-root traversal, in-page fetch, app-specific side effects) that distinguish it from sibling tools like click, type, and dom_snapshot. It also signals it is the fallback when 'no dedicated tool covers' a case, which helps an agent choose it correctly.

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

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

The description gives explicit use cases and implies dedicated tools take precedence ('no dedicated tool covers'). It does not explicitly list which sibling to use instead for common actions, but the provided good uses create a clear boundary. The guidance is usable and context-rich, though it could be stronger by naming alternatives.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the upload action and the absolute-path requirement, which is already in the schema. It does not disclose side effects, event behavior, handling of hidden inputs, 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?

A single well-structured sentence that front-loads the action and target, then adds the critical path constraint. No wasted words.

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

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

The schema fully documents all three parameters, so a valid call can be constructed. However, with no annotations and no output schema, the description does not clarify behavioral expectations, error conditions, or when selector is needed versus ref, leaving some contextual gaps for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions ref/CSS selector and absolute paths, both of which are already documented in the parameter descriptions.

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 ('Upload') and a clear resource ('<input type="file">'), and identifies targeting via ref or CSS selector. It is clear and distinct from siblings like click/type, but it does not explicitly name an alternative or contrast itself with fill_form, so it stops short of a top-tier 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 usage is implied: use this tool when uploading files to a file input. The absolute-path requirement is a useful prerequisite, but there is no explicit guidance about when to prefer this over fill_form/type or any exclusion criteria.

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 delivers meaningful behavioral details: one round-trip, partial errors do not abort, each field reports its own status, and select values can be supplied by value or visible label. These traits go beyond a generic 'fill form' description, though side effects or clearing behavior are not addressed.

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 three tight sentences with no filler. The scope and supported input types are front-loaded, followed by behavioral guarantees and the error-retry instruction. 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 single-parameter tool with no annotations and no output schema, the description gives enough to invoke the tool correctly and recover from failures. It covers supported element types, value semantics, non-aborting partial failures, and a retry path. The only notable gap is the exact shape of per-field status reporting.

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

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

The schema already covers parameter structure with 100% description coverage, so the baseline is 3. The description adds value by explaining type-to-control mapping: booleans for checkboxes/radio buttons, string for text/select, and select matching by value or visible label. This clarifies semantics beyond the raw 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 clearly states a specific action ('Fill a whole form in one call') and enumerates the supported input types: text inputs, select, checkboxes, and radio buttons. It distinguishes fill_form from siblings like click and type by emphasizing the batch, one-round-trip behavior.

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

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

The description conveys when to use the tool: for filling an entire form in one call rather than field-by-field typing/clicking. It also gives an explicit recovery path for per-field errors: call view_page and retry failing fields. It stops short of listing scenarios where fill_form should not be used, but the guidance is still actionable.

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

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

With no annotations, the description carries the behavioral burden. It discloses an important implementation trait: it uses CDP Page.javascriptDialogOpening, so it functions even while the dialog blocks all JavaScript. It also warns that configuration must happen before the triggering action. Minor gaps remain, such as whether the handler persists across dialogs, but the provided behavioral detail is meaningful.

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 no filler. The purpose is front-loaded, and the critical timing caveat and CDP mechanism each earn their 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 two-parameter tool with full schema coverage, the description is largely complete: it explains purpose, timing, and mechanism. The only missing piece is the exact shape of get_status output, but the action is simple enough that the schema enum plus 'pending ones' provides adequate guidance.

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 input schema already fully documents both parameters and the enum values. The description adds no additional parameter meaning, which is acceptable given the baseline for fully covered schemas.

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 ('Configure') and a precise resource ('handling of alerts, confirms and prompts'), clearly distinguishing this from the browser-interaction siblings like click, type, and navigate. No other sibling targets JavaScript dialogs.

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

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

The description gives clear usage context: set this before triggering the action that opens the dialog, and it works even when the dialog blocks JS. It does not explicitly enumerate alternatives or exclusions, but no sibling tool handles dialogs, so the routing is still clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that refs become stale after reload, that the tool waits for settle, that it overwrites the user's active tab, and that the first call per session is redirected to virtual_desk. These are meaningful side effects an agent must know before calling.

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 two sentences long with no filler. The main action is stated first, followed by high-value caveats about stale refs, waiting behavior, and the active-tab overwrite. Every sentence 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?

Given the moderate complexity, no annotations, and no output schema, the description provides a strong set of operational details: what it does, when it redirects, and what side effects occur. It does not mention return values or error behavior, but those are not essential for a navigation action and the schema covers the invocation details.

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 input schema already covers the parameters at 100%, including the enum values, the default action, and the meaning of settle_ms. The description adds little beyond emphasizing the back/reload actions, so the baseline score of 3 is appropriate: the schema does the heavy lifting and the description does not conflict with it.

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

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

The description clearly states a specific action and resource: navigating the active tab to a URL, plus the supported 'back' and 'reload' actions. It further distinguishes itself by noting that it overwrites the active tab and that the first call is redirected to virtual_desk, which prevents confusion with sibling 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?

The description gives practical context about when to use the tool: it explicitly tells the agent to check virtual_desk first and warns that the first call per session is redirected there. It does not spell out a complete set of when-to-use versus when-not-to-use comparisons against all siblings, but the most important alternative is addressed.

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

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

With no annotations, the description carries the behavioral burden. It discloses a non-obvious behavior: the tool captures requests the page itself issues, not just externally visible traffic. The workflow also communicates the stateful lifecycle of start/get/stop. It does not detail return payload shape or repeated-start reset behavior, but schema covers the stop semantics. Overall, it adds meaningful behavioral context beyond the structured fields.

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 with no filler. The first sentence states the core purpose and scope; the second gives the essential workflow. Every part contributes meaning, and the most important information is front-loaded.

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 with three parameters and no output schema, the description provides the essential lifecycle and an example call. However, it does not explain what the get action returns (e.g., status codes, headers, timing data), and there is no guidance on repeated start calls. Since no output schema exists, this missing return-format information leaves the agent somewhat uncertain after invocation. Adequate but not 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 description coverage is 100%, so the baseline is 3. The description adds value by showing how the pattern parameter is intended to be used in the workflow ('get(pattern: "api")'), which illustrates parameter application rather than just listing definitions. This minimal but useful addition justifies slightly above baseline.

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

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

The description states a specific verb and resource: 'Capture network requests via CDP'. It also refines the scope with 'including those the page issues itself', which clearly distinguishes what is captured. No sibling tool overlaps with this function, so the 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?

The description provides a clear workflow: 'start → trigger the action → get(pattern: "api")', which tells an agent the order of operations and how to use the pattern parameter. It does not explicitly mention alternatives or exclusions, but no sibling tool is a natural alternative for network monitoring, so this is acceptable.

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

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

With no annotations provided, the description carries the full disclosure burden, and it delivers meaningfully: it reveals two distinct operational modes (collect and until), the click-ordering guarantee ('click_first fires the triggering action after the observer is armed, so nothing is missed'), and the optional then_click behavior. It stops short of noting the internal polling fallback behind the interval parameter, though the schema documents that parameter.

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 with the main purpose front-loaded in sentence one, followed by compact mode explanations. Every sentence earns its place; the 'so nothing is missed' clause captures an important ordering guarantee in four words without padding.

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

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

The description covers the two execution modes and the click behaviors well, but the tool has no output schema and the description never states what the tool returns after a collect window or when an until condition fires. Constraint details like duration/until exclusivity and the polling-fallback behavior are left entirely to the schema. For an 8-parametter tool with zero annotations, this 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 description coverage is 100%, giving a baseline of 3, and the description adds genuine value on top of the schema: it connects collect to duration, until to then_click, and clarifies the intent of click_first ('fires the triggering action after the observer is armed'). This conceptual grouping makes the parameter model understandable in a way the flat per-parameter schema descriptions alone do not.

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

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

States a specific action (watch an element for changes) on a specific resource (a DOM element via selector), and immediately distinguishes itself from the sibling evaluate tool ('instead of polling with MutationObserver/setInterval code in evaluate'). A new agent can tell what this tool does and how it differs from 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?

The opening line gives a clear when-to-use signal: prefer this tool over hand-written MutationObserver/setInterval polling inside evaluate, which is a concrete alternative. However, the 'until' mode functionally overlaps with the sibling wait_for tool, and the description never mentions that alternative or states when not to use observe, so the routing guidance is incomplete.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It states the core action (pressing a key or shortcut) and the optional focus-first behavior, which is useful. It does not disclose details like whether the key event is dispatched natively, whether modifiers are held during the press, or whether any wait/retry behavior occurs, but the description is not misleading.

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, tightly worded sentence that front-loads the core action and then adds the optional focusing detail. No filler or redundant information is present.

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 relatively simple keyboard-action tool with a fully described schema, the description covers the essential usage and behavior. It lacks an explicit note about return values or post-press page effects, but the tool's low complexity and complete parameter documentation make the definition largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents key, ref, selector, and modifiers. The description adds value with concrete key examples and clarifies the optional focus-first usage of ref/selector, but it does not meaningfully enrich parameter semantics beyond what the schema 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 uses a specific verb ('Press') and a clear resource ('a key or shortcut'), with concrete examples like Enter, Escape, Tab, arrows, and Ctrl+K. This makes the tool's purpose unambiguous and distinguishes it from sibling tools like click (mouse action) or type (text input) without needing to open 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 description implies when to use the tool through examples of keyboard shortcuts and key presses, and mentions the optional focus-first behavior via ref or selector. However, it does not explicitly state when to prefer press_key over siblings like type or click, nor does it provide exclusions or alternative 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 behavioral burden. It discloses server-side execution, variable flow, conditional steps, suspend/resume behavior, error strategies, and parallel groups. It does not cover partial-failure side effects or return values, but the disclosed traits are substantial and accurate.

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 dense but efficient, conveying all major capabilities in a single compact sentence. It could benefit from a structured breakdown, but every phrase carries meaning and the core purpose is front-loaded.

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 complex tool with nested objects and no output schema, the description covers the main operational dimensions: what it batches, how variables work, control flow, suspension, error handling, and parallelism. It does not describe the plan result or how to obtain the planId after suspension, though those are partially in 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 100%, so the baseline is 3. The description adds a useful high-level mapping of features to concepts like $name, if, suspend/resume, errorStrategy, and parallel groups, but it does not materially deepen parameter details beyond what the schema already documents.

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 clearly states the tool batches multiple known actions into one server-side call, explicitly naming click, type, scroll, and view_page chains. This directly distinguishes it from the individual action sibling tools and conveys its orchestration role.

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 says to use this 'instead of N separate calls' for '2+ known actions,' which gives a concrete condition for choosing it over individual action tools. It does not explicitly say when not to use it, but the focus on known actions implies uncertain or exploratory flows should be done step-by-step.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers important runtime behavior: it reports position, detects content growth via scrollHeight delta (useful for lazy-loaded content), and handles settle timing. It does not mention potential side effects or failure modes, but for a scrolling action this is reasonably transparent.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause adds information: scope, behavioral reports, lazy-load detection, settle handling, and container-specific usage. There is no filler or redundant restating of the tool name.

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

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

The tool has six parameters, no required fields, no annotations, and no output schema. The description covers target selection, container behavior, and what is reported, which is enough to invoke it correctly. It could add explicit return structure or failure behavior, but those would be improvements rather than critical 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 100%, so the baseline is 3. The description adds value beyond the schema by explaining the relationship between container_ref/container_selector and direction for scrolling inside a container, which clarifies parameter combinations not fully spelled out 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?

The description uses a specific verb ('Scroll') and explicitly names the resources it operates on: page, container, and element. It further distinguishes itself by mentioning position reporting, content-growth detection, and settle timing, which separates it from navigation or page-view siblings.

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

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

The description gives clear operational context: use ref/selector to scroll into view, direction for page scrolling, and container_ref/container_selector plus direction for container scrolling. It does not explicitly name sibling alternatives or exclusion cases, but the usage context is clearly 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 delivers: chunking behavior, the page-side contract (`__complete` flag), encoding-dependent consumer types (string vs ArrayBuffer), and a concurrency race warning. This is a high level of disclosure for a tool with no structured hints.

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?

Every sentence carries useful information and the core purpose is front-loaded. It is slightly denser than necessary and partially repeats source options already in the schema, but there is no filler or padding.

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

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

The description thoroughly covers input modes, page behavior, safety, and alternatives. However, it never states what the tool call returns or whether it resolves after chunks are sent versus after the page sets `__complete`. With no output schema, this is a meaningful gap for an agent deciding how to observe completion.

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 the baseline is 3. The description adds meaningful context on top: inline vs file source semantics, binary reading for files, and how encoding affects whether the page receives a string or ArrayBuffer. This goes beyond the schema's raw type descriptions.

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 ('Write'), a specific target (`window.__pb_data[key]`), and a distinguishing mechanism (chunking past the CDP 1 MB limit). It is clearly differentiated from siblings like `evaluate` and `file_upload`, which are explicitly named as alternatives.

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

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

Provides explicit when-to-use guidance: payloads larger than 1 MB. It also names excluded alternatives: use `evaluate` under ~200 KB and `file_upload` for real `<input type=file>` cases. The warning about parallel writes to the same key adds important usage constraint.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly warns that refs from the previous tab are invalid afterward and tells the agent to call view_page before acting, which is a key side-effect beyond what the schema reveals.

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

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

Three short sentences deliver all essential guidance with no filler. The main action set is front-loaded, followed by the usage caveat and the critical invalidation warning, each earning 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?

The description covers the three actions, the source of tab IDs, the open-vs-navigate decision, and the invalid-ref consequence, which is strong for a tool without annotations or an output schema. It could be slightly more explicit about post-open/switch state, but the provided guidance is sufficient for correct invocation in most cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by specifying that tab IDs come from virtual_desk and by clarifying the open behavior relative to the active tab, going slightly beyond the schema's parameter descriptions.

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 clearly enumerates three specific operations—open, switch, and close—on tabs, and ties tab IDs to virtual_desk. It is differentiated from navigate by explicitly preferring open when the active tab must stay untouched.

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 explicit guidance to prefer open over navigate when the active tab must remain unchanged, which is a concrete decision rule. It also instructs that view_page should be called after switching because old refs are invalid, though it does not fully cover when to use alternatives like tab_status.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It honestly states the data is cached, implying it may not be perfectly live, and characterizes the call as cheap, signaling low cost. It also mentions errors are included, giving useful behavioral context beyond a simple 'get status' phrasing.

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 deliver a dense but readable description: what the tool returns, the typical use case, and a clear boundary. Every phrase earns its place, and the most important identifying information is front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is complete: it lists the returned fields (URL, title, ready state, errors), the scope (active tab), the performance profile (cheap), and the appropriate use case. Nothing essential is missing for an agent to decide whether and when to invoke it.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies because no parameter documentation is needed and the description appropriately focuses on what the tool returns rather than input details.

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 clearly identifies the tool as returning the active tab's cached URL, title, ready state, and errors, which is a specific, concrete resource. It also explicitly distinguishes itself from tools for tab discovery or page content, preventing confusion with siblings like switch_tab, view_page, or dom_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 description gives a clear when-to-use scenario: a cheap mid-workflow sanity check, exemplified by 'did my click navigate?'. It also provides an explicit when-not-to-use boundary (not for tab discovery or page content), though it does not name specific alternative tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action and target mechanism. It does not disclose whether the field is focused or clicked first, whether text overwrites existing content or appends to the cursor position, what happens when neither ref nor selector is provided, or how multiple matching selectors are handled.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the sibling-routing guidance is compact and immediately actionable.

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?

Despite a complete schema, this is a mutation-oriented tool with no annotations and no output schema. The description leaves important operational gaps undefined: target resolution when ref/selector is absent, clearing semantics, return/failure behavior, and handling of ambiguous element matches. The sibling routing helps but does not make the description 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 description coverage is 100%, so the schema already documents ref, text, clear, and selector meaningfully. The description largely restates 'ref or CSS selector' without adding substantive value beyond what the parameter descriptions already give, landing at the baseline of 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?

The description opens with a specific verb and resource: 'Type text into an input identified by ref or CSS selector.' It clearly differentiates itself from sibling tools by explicitly naming fill_form and press_key as the alternatives for multi-field and special-key scenarios.

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 explicitly states when to use the tool ('Type text into an input') and when not to: 'For 2+ fields use fill_form; for special keys (Enter, Escape, Tab, arrows) or shortcuts (Ctrl+K) use press_key.' It also communicates the ref-preferred, selector-fallback targeting strategy.

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 of behavioral disclosure. It discloses that the output includes stable refs, that collapsed containers show summaries like '[eXX role, N items]', and that follow-up expansion calls are possible. This is meaningful behavior beyond the schema and helps the agent anticipate output shape.

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, each earning its place: the core purpose comes first, then filter usage, then expansion behavior. There is no filler or redundant restatement of the schema.

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

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

For an inspection tool with four optional parameters and no output schema, the description is largely sufficient: it specifies the return content, default behavior, and how to get broader or expanded views. The main gap is the absence of explicit differentiation from sibling inspection tools, but the core calling pattern is fully covered.

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

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

Schema description coverage is 100%, so a baseline of 3 applies. The description adds practical meaning by mapping the 'filter' parameter to specific scenarios and explaining how 'ref' is used to expand collapsed subtrees, going beyond the schema's enum descriptions.

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 action and resource: 'See what is on the page: text plus stable element refs for click/type/fill_form.' It clearly communicates what the tool returns and why it is useful, distinguishing its role from generic page-capture tools even without naming a sibling.

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

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

The description gives explicit guidance for variant usage: default filter 'interactive' lists actionable elements, filter 'all' is for paragraphs/table cells, and collapsed containers are expanded via view_page(ref, filter: 'all'). It does not compare against sibling inspection tools like dom_snapshot or observe, but it clearly tells the agent when to adjust the 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and adds useful context about cost and call frequency. It does not explain what 'state' includes or what happens if no tabs are open, but for a simple listing tool this is a minor 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?

Three sentences with zero fluff: the core purpose is front-loaded, followed by direct usage instructions and a cost hint. Every sentence adds actionable information.

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

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

For a zero-parameter listing tool with no output schema, the description is complete: it states what is listed, when to call it, how to use the results, and how often it may be invoked. No missing information is needed to call or interpret the tool 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 has zero parameters, so the baseline is 4; the description correctly implies no input is needed. It adds no parameter-specific detail because none exists, which 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 begins with a specific verb and resource: 'List all open tabs with IDs, URLs and state.' This clearly distinguishes it from sibling tools like switch_tab or tab_status, which operate on specific tabs or current tab state rather than enumerating everything.

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 provides explicit when-to-use guidance: 'Call it first in every session, after a reconnect, or when unsure.' It also tells the agent to reuse listed tab IDs instead of opening duplicates, and explicitly states the cost profile: 'Cheap, call liberally.'

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains the core polling-style behavior, the five condition types, and the critical assert mode that checks once and fails instead of waiting. This is meaningful behavioral context beyond the bare 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?

Three sentences with no filler. The main purpose is front-loaded, condition selection guidance is next, and assert behavior is saved for last. Every sentence 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?

The tool is moderately complex with seven parameters and no annotations, but the schema covers every parameter and the description covers the core behaviors and condition choices. It could go further by mentioning timeout failure behavior or the relationship to observe, but as paired with the schema it is largely complete 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 description coverage is 100%, so the baseline is 3. The description adds value by advising when to use 'text' instead of a JS expression, which helps an agent choose the correct condition parameter. It also clarifies the semantic effect of assert, adding meaning beyond the parameter descriptions.

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?

Theescription clearly states what the tool does: wait until a condition holds, and enumerates the supported condition types (element, text, URL, network_idle, JS). It is specific about the resource and actions, but does not explicitly differentiate itself from sibling tools such as observe, so it loses the full marks for sibling diistinction.

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 provides useful internal selection guidance, particularly preferring condition 'text' over JS expressions for checking page text, and explains the assert: true behavior. However, it does not address when to use wait_for versus a sibling tool such as observe or evaluate, so the usage guidance is partial.

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