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

With no annotations, the description carries the full burden, and it does meaningful work: it discloses the trusted-CDP-by-default behavior with DOM-event fallback and that the tool waits for navigation when one starts. It omits failure semantics (what happens if the element is not found or the action is blocked) and timeout/retry behavior, which keeps it short of a 5.

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

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

Two tight sentences, front-loaded with the action and targeting options. Every clause carries information an agent can act on, and there is no filler.

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

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

For a tool with no annotations, no output schema, and 18 parameters, the description covers the core behavioral contract but leaves notable gaps: nothing about the return value or error shape, nothing about how x/y must be supplied together, and no mention of the timing-related parameters.

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 28% across 18 parameters, so the description must compensate. It usefully explains the targeting hierarchy (ref > selector > text > coordinates) and the trusted/CDP fallback that maps to the 'trusted' param, but it leaves button, modifiers, clickCount, tabId, frameId, delayAfter, exactText, and switchToNewTab undocumented beyond the bare schema names.

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 (Click) and resource (an element), and enumerates the four targeting strategies with 'ref' marked preferred. It is unambiguous on its own, but it never distinguishes itself from near-neighbor siblings such as hover, drag, or select, so it falls short of the explicit sibling differentiation a 5 requires.

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?

'ref (preferred)' gives in-tool guidance for choosing among targeting modes, which is genuinely useful. However, there is no guidance on when to use click versus siblings like hover, drag, press, or evaluate, and no prerequisites or exclusion conditions 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?

With no annotations, the description carries the full burden, and it does disclose the buffer semantics ("captured since page load") and that clear resets it — useful, non-obvious traits. However, it omits whether a tabId is needed, whether the call is scoped to one tab, and any rate/size behavior (the 200/400 limit caps).

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

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

Two tight sentences with zero filler; the core behavior is front-loaded and the clear-buffer hint is a compact, high-value second sentence.

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

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

No annotations, no output schema, and 0% schema coverage on a 4-parameter tool means the description should do more. It never explains the return shape (entries, ordering, truncation) or the role of `limit`/`tabId`, leaving an agent unable to invoke it confidently.

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% across 4 parameters, so the description must compensate and largely doesn't. It touches `action` via the clear example and loosely gestures at `level` through the enumerated event types, but `limit` (default 200, max 400) and `tabId` are completely undocumented anywhere.

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 (read console logs) and enumerates the captured event types (warnings, errors, unhandled rejections), which makes it distinct from most siblings. It does not explicitly separate itself from near neighbors like `debugger` or `network`, so it falls short of full sibling differentiation.

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

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

The description gives one concrete usage instruction: use action="clear" to reset the buffer. It offers no guidance on when to reach for console output versus `debugger`, `network`, or `evaluate`, and no prerequisites (e.g., requires an active tab). Usage is implied rather than framed as a decision.

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

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

No annotations are provided, so the description carries the full burden. It usefully notes that values are returned to the model and warns to handle secrets carefully, but it omits that set/delete/clear are mutating and potentially destructive operations, what permissions they need, or what happens on clear-all. For a tool with destroy semantics this is a significant 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?

Two sentences, front-loaded with purpose and ending with the safety warning. No wasted words, though the safety note would earn more if paired with action-level detail. Size is appropriate.

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?

A 12-parameter mutation-capable tool with no annotations and no output schema demands far more disclosure than given. The action enum, credential/session impact of clearing cookies, and store/tab scoping are all left unexplained, leaving the agent under-informed.

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?

12 parameters with 0% schema description coverage and no parameter explanation in the description. Complex params like storeId, tabId, sameSite, and the action enum are entirely undocumented, and the description does not compensate for the schema gap at all.

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

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

States specific verbs and resource ('Read, set, delete or clear cookies') and names the underlying Chrome cookies API, which clearly separates it from siblings like network or tabs. The scope is broad (four actions collapsed into one tool) but the resource 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 offers no when-to-use guidance, no indication of which action to pick, and no prerequisites. Nothing tells the agent when to reach for this tool versus inspecting DOM, network, or tabs data. The only usage note is a generic secrets warning.

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

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

With no annotations, the description carries the full burden and does add one concrete behavioral trait: attaching shows a Chrome debug banner. It does not disclose whether attaching is disruptive, what permissions are needed, whether detach cleans up, or any side effects beyond the banner.

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, front-loaded with the core action, followed by capability context and a behavioral note. No wasted words, though the capability list is somewhat enumerative 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?

For a low-complexity toggle with only two parameters and no output schema, the description covers the actions, their purpose, and one behavioral detail. It still omits auth/permission requirements and the relationship to the 'status' sibling, leaving partial gaps for an agent acting without annotations.

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 compensate. Its verbs 'show, attach or detach' loosely map to the action enum (status/attach/detach), which helps, but the tabId parameter and the default 'status' action are left entirely unexplained.

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

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

States a specific verb set (show/attach/detach) and resource (Chrome debugger for a tab), and explains the CDP capabilities it unlocks. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like 'status' which could also expose debugger state.

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

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

Usage is implied via the capability list (trusted input, screenshots, evaluation, uploads, emulation) - an agent can infer you attach when those are needed. However, there is no explicit when-to-use guidance, no exclusions, and no mention of the 'status' default action or how it relates to the 'status' sibling tool.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that interception prevents dialogs from blocking automation and that a log of recent dialogs exists, which is real context. However, it does not say what clearing destroys, whether a default policy applies on first use, or what inspection returns.

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

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

Two sentences with zero filler; the operational modes are front-loaded and the behavioral caveat follows. Every clause contributes 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 five-parameter tool with no annotations, no output schema, and 40% schema coverage, the description covers the core actions but omits the intercept flag's effect and the tabId scoping. It is adequate to start, 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 only 40% (only prompt and confirm are documented), so the description must compensate. It explains the three action modes but leaves tabId and intercept opaque, and never states that prompt/confirm supply the answers used for future dialogs. It adds partial meaning over the schema but does not close the gap.

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

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

The description uses specific verbs (inspect, clear, change) tied to a concrete resource (alert/confirm/prompt dialogs), so an agent understands this manages JS dialogs rather than general page state. It lacks explicit contrast with siblings like console or evaluate, but the resource is distinct enough to separate it.

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

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

Usage is implied through the three enumerated modes (inspect, clear, change policy), which maps loosely to the action enum, but there is no explicit statement of when to use this versus alternatives such as console or evaluate, nor any prerequisites. The 'interception avoids blocking automation' line hints at the motivating context but is not a routing rule.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies read-only behavior through 'Query' and adds shadow DOM support, but it does not state that it is non-destructive, how timeouts or waiting behave, or whether it can operate across frames and tabs.

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 front-loaded sentences with no obvious filler. The second sentence provides a concrete shadow DOM example, though the first sentence could be slightly tightened by grouping return types.

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 12 parameters, no annotations, no output schema, and very low schema description coverage, the description is far too sparse. It covers the general purpose and shadow DOM syntax but omits critical operational details needed to invoke 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 only 8%, leaving 11 of 12 parameters undocumented in the schema. The description adds the shadow DOM '>>>' syntax for selector and names the possible action outputs, but it does not explain all, ref, limit, tabId, xpath, frameId, timeout, maxLength, includeHtml, or the default behavior.

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

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

The description states a specific verb ('Query') and resource ('DOM elements') and lists the types of return data, so the core purpose is clear. However, it does not explicitly differentiate this tool from sibling inspection tools like evaluate or snapshot, so an agent must infer the boundary.

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

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

The description gives no guidance on when to use dom versus alternatives such as evaluate, snapshot, or highlight. It does include a useful shadow DOM selector syntax example, but that is a usage detail rather than a when-to-use rule.

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

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

With no annotations, the description carries the full burden, and it does disclose a meaningful implementation trait: real mouse events under CDP with synthetic pointer/drag fallback. However, it omits permissions, error behavior, return values, and what happens on unsupported surfaces — significant gaps for an interaction tool.

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

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

Two tight sentences with the mechanism and the applicability front-loaded; nothing is wasted. It is close to optimal for what it covers, though brevity here comes partly at the cost of the missing parameter detail.

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 13-parameter, zero-annotation, no-output-schema mutation-style interaction tool, the description is far too thin. It leaves selectors vs coordinates, timing, step count, and frame/tab targeting entirely undocumented.

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

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

There are 13 parameters at 0% schema description coverage, and the description adds essentially nothing beyond the vague hint that a source and target can be an 'element/point'. Parameters like steps, duration, trusted, tabId, and frameId are entirely unexplained in both schema and description.

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 — 'Drag from one element/point to another' — so an agent immediately knows this performs a drag gesture, distinct from click/hover siblings. It stops short of explicitly naming those alternatives, which a 5 would require.

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 line 'Works for pointer-based UIs and many HTML5 drop zones' implies when this is applicable, and 'when CDP is available' hints at a precondition, but there is no explicit when-to-use/when-not guidance or named alternative tool. Usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that CDP is required and that reset clears overrides, but says nothing about whether overrides persist across navigations, how partial sets behave, or what the tool returns. Adequate but with real gaps for a state-mutating tool.

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

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

Two tight sentences, front-loaded with the emulation scope and ending with the reset escape hatch. No filler 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?

For a 16-parameter, annotation-free, no-output-schema mutation tool, the description covers the conceptual parameter surface but leaves behavioral details (persistence, return values, error modes) and several parameters (tabId, default action) unaddressed. It is a usable but not complete brief.

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% across 16 parameters, so the description must compensate. It names most emulation axes (viewport size, device scale, mobile, user agent, geolocation, color scheme, timezone, network conditions), which maps conceptually onto width/height, deviceScaleFactor, userAgent, lat/long/accuracy, colorScheme, timezone, offline/latency/throughput. However, it omits the default action="set", tabId, and any units or formats for numeric fields like latency and throughput.

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 (emulate) and enumerates the exact resources it affects: viewport size, device scale, mobile, user agent, geolocation, color scheme, timezone, and network conditions. The purpose is unambiguous, though it does not explicitly differentiate itself from siblings like network or screenshot.

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

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

It gives a prerequisite ("Requires CDP") and a concrete operational instruction ("Use action=\"reset\" to clear overrides"), which tells the agent how to undo state. It stops short of naming when-not-to-use cases or alternative tools, so it is clear context without full routing.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses execution context (page main world) and return format, and 'Powerful' hints at risk. However, it never states that this runs arbitrary code with page privileges, can mutate/destroy page state, or what permissions/userGesture gating applies — significant omissions for a mutation-capable 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?

Three tight sentences, front-loaded with purpose, followed by the practical IIFE pattern and the alternative guidance. The example earns its space by showing the required expression format; no filler.

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

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

For a 7-param, no-annotation, no-output-schema tool, the description covers purpose, return type, and the expression convention but leaves six parameters and the safety/mutation profile undocumented. Adequate as a starting point, incomplete given the tool's complexity and risk.

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% across 7 parameters. The description does explain the required 'expression' param with a concrete IIFE example, but tabId, frameId, trusted, userGesture, awaitPromise, and returnByValue are entirely undocumented in both schema and description.

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 — 'Execute JavaScript in the page main world' — and names the return type ('return a JSON value'). It also references sibling alternatives ('prefer snapshot/DOM'), so an agent can distinguish its role from dom and snapshot without opening a 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?

Explicitly tells the agent when *not* to reach for this tool ('prefer snapshot/DOM when possible'), which is a real routing rule against named siblings. It stops short of enumerating when this tool IS the right choice, but the context is 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, the description carries the full behavioral burden and discloses little: it does not explain that 'submit' triggers form submission (a consequential side effect), what 'trusted' changes about event synthesis, or how 'continueOnError' alters failure handling. Only field addressing and type values are 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?

Two compact sentences with the core capability front-loaded and no filler. The second sentence partially restates the schema's enum, but with 0% schema coverage that restatement still 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 6-parameter tool with a deeply nested fields array, no annotations, and no output schema, the description omits too much: submission semantics, error-handling behavior, timeouts, and trusted-event behavior are all unaddressed. An agent can call it, but not confidently for anything beyond the simplest text fill.

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% and the description clarifies only two things: fields accept ref or selector, and type is one of four enum values. The other top-level parameters (tabId, submit, timeout, trusted, continueOnError) and nested options (clear, delay, index, label, value, values, checked, frameId, pressEnter) remain unexplained in both schema and description.

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

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

States a specific verb and resource ('fill multiple fields'), and the phrase 'in one call' implicitly contrasts with the single-field type/select siblings. It does not name an alternative tool outright, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is the batched alternative to repeated type/select calls, but the description never states when to prefer it or when a single-field tool is more appropriate. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full burden. "Temporary" and "over the live page" usefully signal an ephemeral, non-persistent overlay, but it omits the show/clear action semantics, any duration behavior or limits, and confirmation that the page is otherwise unmodified.

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

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

Two sentences, front-loaded with the core action and targeting modes followed by a brief use-case note. No wasted text, though the second sentence is thin relative to the disclosure gaps.

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 9-parameter tool with zero schema coverage, no annotations, and no output schema, the description leaves too much unstated: clearing behavior, timing, color, and frame/tab targeting. It is not complete enough for an agent to invoke confidently.

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% across 9 parameters, so the description must compensate. It maps only ref/all/selector/text to the three targeting modes; color, tabId, frameId, action (show/clear), and durationMs are entirely undocumented in both schema and prose.

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 (draw) and resource (temporary labeled outlines) plus the three targeting modes: single element, all elements with refs, or selector/text match. It is clearly distinguishable from visual siblings like screenshot and snapshot, though it does not name 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?

"Useful for visual debugging and demos" implies the usage context but gives no when/when-not guidance and no comparison to alternatives such as snapshot, dom, or screenshot, which an agent would need to choose correctly among the many inspection 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, the description carries the full burden, and it does disclose a genuine behavioral trait: it drives a real mouse via CDP and degrades to synthetic events when CDP is unavailable. That is useful context beyond structured fields, but it omits timing/targeting behavior, whether the pointer state persists, and any environment/permission constraints.

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

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

Two tight sentences with no filler; the core action and its outcomes are front-loaded, followed by the fallback caveat. 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 9-parameter tool with no annotations and no output schema, the description is too thin. It does not explain the target-selection params (ref/text/selector), the trusted flag, step-based movement, or the durationMs post-hover hold, leaving significant gaps for an agent trying to invoke it correctly.

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

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

Schema description coverage is only 22% across 9 parameters, so the description should compensate but adds nothing about ref, text, selector, trusted, steps, or durationMs. Two parameters (duration, durationMs) are documented only in the schema, and the description never clarifies which targeting param takes precedence.

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 (move the real mouse over an element) plus the concrete outcomes it enables (CSS :hover, tooltips, menus), which separates it from siblings like click and press. It is clear and self-contained, though it never names an alternative tool it competes with.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives (e.g., click vs hover, highlight vs hover). The fallback sentence is behavioral, not usage guidance. An agent must infer the use case from the purpose statement alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the blocking semantics ('Waits for the requested load state'), but omits what happens on timeout, failure behavior, permission requirements, or that bypassCache/timeout alter the wait.

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 with the action set front-loaded and the newTab tip last. Every clause carries information; nothing is 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?

For an 8-parameter, no-required, no-annotation, no-output-schema tool, the description covers the core actions but is silent on several parameters and on error/timeout behavior. Adequate but with visible gaps.

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

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

Schema coverage is only 38%, so the description needs to compensate. It clarifies url, action values, newTab, and links waitUntil to the 'requested load state', but leaves tabId, active, timeout, and bypassCache entirely unexplained.

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

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

States a specific verb (navigate) plus the enumerated actions (goto/back/forward/reload/stop) and the resource (URL / active tab). It is clearly distinguishable from most siblings, though it never names an alternative tool to route between.

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 only guidance is a parameter tip ('Use newTab=true to open in a new tab'), which is invocation detail rather than when-to-use context. There is no mention of when to prefer this over siblings like wait_for, tabs, or evaluate, and no 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 no annotations, the description carries the full burden, and it frames the tool purely as a read while the schema exposes action=clear, which destroys captured data — that destructive capability is never disclosed. It also omits whether capture is bounded, requires a specific tab, or resets on navigation, though the 'since page load' scoping is useful.

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

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

Two tight sentences with the core scope front-loaded and the optional flag second. Nothing is wasted, though it is arguably too short given seven parameters.

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

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

For a 7-parameter, zero-annotation, no-output-schema tool, the description is far too thin: the destructive clear path is undisclosed and most parameters are unexplained in either schema or description. An agent could not reliably invoke anything beyond the default read.

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

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

Schema coverage is only 29%, so the description must compensate, yet it only explains includeStatic. The action enum (get/clear), limit, tabId, status, and the filter semantics are left entirely undocumented, and the mention of 'status' refers to returned data rather than the status filter parameter.

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

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

States a specific verb+resource ('Read fetch/XHR requests captured since page load') and names the returned fields (status, duration, errors), which clearly separates it from siblings like console or dom. It never explicitly names an alternative sibling, so it stops short of a 5.

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

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

The includeStatic=true sentence gives real conditional guidance on one option, but there is no statement of when to prefer this tool over console or evaluate, and no mention of the clear action's use case. Usage is implied rather than framed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that Enter submits forms by default (only inferable from the noSubmit param), nor what trusted, delay, waitUntil, or timeout do, nor 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?

Two compact sentences, front-loaded with the concrete key examples, with no filler. Efficient, though the second sentence is thin relative to the tool's complexity.

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?

A 10-parameter browser automation tool with no annotations and no output schema needs substantially more description than two sentences. Key behaviors (form submission, trusted input, wait semantics, failure modes) are all missing.

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

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

Schema description coverage is only 10% (just noSubmit), so 9 of 10 parameters are undocumented. The description adds useful key-syntax examples and mentions focusing an element, but leaves delay, tabId, frameId, timeout, trusted, waitUntil, and selector semantics entirely unexplained.

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

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

States a specific verb (press) and resource (key or key combination), and the examples (Control+A, Shift+Enter, F5) make clear this is for keystrokes rather than typing text. It does not explicitly contrast itself with the sibling 'type' tool, so an agent must infer the boundary.

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?

'Optionally focus an element first' hints at the ref/selector parameters, but there is no guidance on when to use press versus type or click, nor any stated prerequisites or page-state conditions. Usage is left almost entirely 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?

No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral fact ('Returns an image the model can see'), but says nothing about permissions, the trusted/CDP toggle semantics, timeout behavior, or how quality/format affect the capture.

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 tight sentences, no filler, with the capture scopes front-loaded and the flag behaviors following. 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?

With 13 parameters, no annotations, and no output schema, the description is only minimally sufficient. It usefully notes the image return value (which compensates for the missing output schema) but does not cover the majority of the parameters, leaving real gaps for a tool of this complexity.

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

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

Schema coverage is only 46% and there are 13 parameters. The description adds meaning for grid, annotate, fullPage, and implicitly ref/selector, but leaves tabId, frameId, format, quality, timeout, trusted, maxWidth, and maxHeight undocumented in both schema and description.

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 ('Capture') and resource ('viewport, full page, or one element'), and the three capture scopes are clearly itemized. It does not, however, distinguish itself from the sibling 'snapshot' tool, which an agent could reasonably confuse with a visual capture.

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

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

The description explains what the annotate and grid flags do, which implies when to use them, but gives no guidance on when to choose screenshot over 'snapshot' or any other sibling. Usage is implied rather than stated, with no when-not conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one genuinely useful trait beyond the schema—'Uses trusted mouse wheel events when CDP is available'—which matters for anti-bot detection, but it omits permissions, side effects, and what is returned.

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 written sentences with the primary capability front-loaded and the CDP/trusted-event caveat appended as secondary detail. Every clause earns its place; nothing is padded.

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 zero schema descriptions, no annotations and no output schema, the description is too thin: it says nothing about defaults (amount=600, direction=down), the trusted/smooth interplay, or how frame and tab targeting work. An agent would have to guess at most parameter behavior.

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

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

Schema description coverage is 0% across 11 parameters, so the description must compensate and largely does not. It hints at 'page or a container' (containerRef/containerSelector), 'top/bottom' (to enum) and 'element into view' (ref/selector), but leaves amount, direction, smooth, trusted, frameId and tabId completely unexplained.

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

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

The description names a specific verb (scroll) plus its three modes: free scrolling, jumping to top/bottom, and bringing an element into view. It clearly distinguishes the tool's scope from siblings like click/type/hover, though it does not explicitly contrast itself with any named 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?

Enumerating the three scroll modes implies when the tool applies (e.g., bringing an off-screen element into view), but there is no explicit guidance on when to choose scroll over alternatives such as evaluate, or prerequisites like needing a target page/tab first. Usage is inference-only.

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

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

No annotations are provided, so the description carries the full burden. It discloses that one OR more options can be selected (multi-select support), which is useful behavior, but says nothing about what happens on failure, whether selection replaces or appends in a multi-select, or any permission/race considerations.

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, zero waste, and the positive case plus the excluded case are both front-loaded. Nothing needs trimming.

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 10-param, no-annotation, no-output-schema tool, the description covers intent and the sibling alternative but leaves the element-targeting params (ref/selector) and scoping params (tabId/frameId) undocumented. Adequate for the core call, incomplete for the full parameter 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 0% across 10 parameters, so the description must carry the load. It explains the value/label/index selection families (including plural variants), but leaves ref, selector, tabId, and frameId completely unexplained in both schema and description.

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

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

States a specific verb (choose/select) and resource (native <select>), and explicitly distinguishes itself from the custom-dropdown path by naming the chrome_click sibling. An agent can tell this apart from click/hover without opening the schema.

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

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

Gives an explicit when-not with an alternative: for native selects use this, for custom dropdowns click the trigger then use chrome_click. It lacks guidance on when to prefer value vs label vs index, but the core routing decision is spelled out.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape (tree with refs) and the frame-scoping trait ('Refs belong to a frame'), which is genuinely useful behavior. However, it never states that the operation is non-mutating, how it behaves on timeout, or what happens when maxDepth/maxNodes truncate the tree — meaningful gaps for a 10-parameter 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?

Three short, front-loaded sentences with zero filler. The core capability comes first, the workflow cue second, and the frame caveat last — a well-ordered, appropriately sized description.

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?

There is no output schema, so the description rightly sketches the return value (accessibility tree with refs), which helps. But with 10 optional parameters, no annotations, and 40% schema coverage, the agent is left guessing about mode, depth/node limits, and hidden-element handling — a notable shortfall for a tool this configurable.

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

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

Schema description coverage is only 40%, so the description must compensate and largely does not. It explains allFrames and hints at frameId via the ref/frame relationship, but says nothing about mode ('interactive' vs 'full'), timeout, maxDepth, maxNodes, includeHidden, or tabId — six parameters with no documentation anywhere.

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 ('Return a compact accessibility-style tree') plus its distinguishing feature: stable refs like f0_e12 for interactive elements. An agent can immediately separate this from siblings like dom, screenshot, or evaluate, which return different representations of the page.

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 prescribes the workflow: 'Do this before clicking or typing.' That is a clear when-to-use cue. It also gives a conditional for iframe coverage (allFrames=true). It stops short of naming an alternative tool (e.g. dom) or a when-not-to-use case, so it isn't a full 5.

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

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

With no annotations, the description carries the full disclosure burden, and it does convey that this is a read-only diagnostic ('check', 'list', 'show') with no side effects. However, it says nothing about return format, whether the connection check can fail, or what an agent should do with the result, which leaves gaps for an unannotated tool.

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

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

Two tight sentences, front-loaded with the capability and followed by the usage trigger. Every clause earns its place and nothing is repeated from the name or 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 a zero-parameter diagnostic tool with no output schema, the description covers what is checked (connection, tabs, active tab) and when to reach for it. It is close to complete, missing only a hint about the shape or limits of the reported status.

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

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

The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to disambiguate, and it correctly implies a no-argument invocation.

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

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

The description gives specific verbs and resources: check extension connectivity, list open tabs, report the active tab. That is clear enough to separate it from action-oriented siblings like click, navigate, or screenshot, though it never names an alternative tool explicitly.

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

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

It provides an explicit trigger condition: 'Call this first when browser tools seem unavailable.' That is a genuine usage cue rather than implied guidance. It stops short of stating when not to call it or naming a fallback if this tool also fails.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that 'close' is destructive, that 'reload'/'duplicate' mutate state, what permissions are needed, or how errors surface – for a multi-action mutation tool with zero annotation coverage this is a significant 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?

Two short sentences that are front-loaded with the core verb list. The second sentence largely duplicates the schema's action enum, which is wasteful repetition, but the overall size is appropriate.

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 9 parameters, 33% schema coverage, no annotations, and no output schema, the description is far too thin to call this tool correctly. It provides no return-value hints, no per-action parameter mapping, and no prerequisite or permission context.

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

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

Schema description coverage is only 33%, so five parameters (pinned, timeout, windowId, waitUntil, bypassCache) are undocumented everywhere, and the description compensates for none of them. It merely re-lists the action enum that the schema already defines, adding no meaning about url defaults, tabId fallback behavior, or waitUntil 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 concrete verbs and a clear resource (Chrome tabs), and enumerates the supported actions, so an agent knows it is the tab-management tool rather than a page-interaction sibling. However, the two sentences are internally inconsistent: the first omits 'get' and 'unmute' while the action list includes them, and no sibling is named for contrast.

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 lists actions but never says when to use this tool versus navigate, snapshot, or click, nor when to prefer one action over another. Usage must be inferred entirely from the action names themselves.

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

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

With no annotations, the description must carry the behavioral burden. It does add genuine value beyond the schema by disclosing that the field is cleared by default, that input uses 'trusted CDP keystrokes', and the focused-element fallback. It omits other meaningful traits like timeout behavior, waiting semantics, and per-character delay effects.

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 focused sentences, each carrying distinct operational information (targets, clear-by-default, trusted keystrokes, submit flag, focused fallback). No filler or redundancy; it is front-loaded with the core action.

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

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

For a 13-parameter mutation-style tool with no annotations and no output schema, the description covers only the headline behaviors. Many parameters and failure/timeout semantics remain undocumented, leaving gaps an agent would want filled before calling it reliably.

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

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

Schema coverage is only 23% across 13 parameters, so the description must compensate and largely does not. It clarifies clear (default), focused, and pressEnter, but leaves delay, delayAfter, timeout, waitUntil, trusted, selector, ref, tabId, and frameId unexplained in both schema and description.

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

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

States a specific verb (type) and the target resources (input, textarea, contenteditable) clearly. However, it does not distinguish itself from the close sibling fill_form, which also enters text into fields, so an agent must infer the boundary.

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 implied usage clues: it explains the no-target fallback ('types into the focused element') and how to submit ('Set pressEnter=true'), which helps invocation. But there is no explicit when-to-use-this-vs-alternatives guidance against fill_form, click, or press.

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

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

With no annotations, the description carries the full burden, and it does disclose two non-obvious environment constraints: CDP is required and the operation only works in the top frame. However, it says nothing about side effects on any previously selected files, whether change events fire, permissions, or failure modes, which is a notable gap for a mutation tool.

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

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

Two tightly written sentences with the core action front-loaded and prerequisites second; no filler or repetition. Slightly terse on how the target element is identified, but nothing is wasted.

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

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

For a 5-parameter mutation tool with 0% schema coverage and no annotations or output schema, the description is thin. It omits how the file input is targeted (ref vs selector), tab/frame selection semantics, overwrite behavior, and error conditions, leaving the agent under-informed before invoking.

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% across 5 parameters, so the description must compensate and largely doesn't. It adds one useful clarification ('absolute paths on the machine running Chrome') for the required files array, but ref, selector, tabId, and frameId — including how the target input is located or which frame/tab is used — remain entirely undocumented.

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

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

The description gives a clear verb and a precise target resource: 'Set one or more files on an <input type="file">'. An agent can distinguish this from fill_form/type/select because it names the specific DOM element type it operates on. It stops short of explicitly contrasting itself with those siblings, so a 5 isn't warranted.

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 states a precondition ('Requires CDP and the top frame') but gives no when-to-use versus when-not guidance and names no alternative tools. There is no indication of when this tool should be preferred over e.g. fill_form or how it fails if the prerequisites aren't met.

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 of behavioral disclosure and does not meet it. It says nothing about what happens on timeout (error vs. silent return), that timeout defaults to 10s and caps at 120s, the 200ms polling interval, or whether only one wait can be active at a time.

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 with no padding, and the capability list is front-loaded ahead of the usage hint. Nothing is wasted, though the terse enumeration leaves the reader parsing unformatted prose rather than a scannable 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 a 13-parameter, zero-required tool with no annotations and no output schema, this description is far too thin. An agent cannot tell how the condition parameters interact, what a timeout produces, or which parameters are required to make a valid call.

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

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

Schema description coverage is only 15% across 13 parameters, so the description must compensate and largely does not. Enumerating the four condition families loosely maps to js, selector/text, urlMatches/urlIncludes, and loadState, but state, exact, trusted, timeout, interval, tabId, and frameId remain undocumented, and the critical question of whether these condition modes are mutually exclusive or combinable is unanswered.

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 (wait) and enumerates the four condition families it accepts: selector/text state, URL, JavaScript predicate, and page load state. That is enough to separate it from siblings like evaluate, snapshot, or navigate without opening the schema. It stops short of explicitly naming which siblings are the 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?

"Use after actions that trigger async updates or navigation" gives clear situational context for when to reach for this tool rather than polling manually. It offers no when-not guidance (e.g., do not use if the element is already synchronously present) and does not point at an alternative tool.

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