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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds what the agent otherwise could not know: it returns per-criterion scores, findings and fixes. It leaves out whether the page must be fully loaded or how long the audit takes, which keeps it from 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?

One front-loaded sentence with the purpose first and the criteria list second; every clause carries information. The criteria enumeration is long but necessary to distinguish the tool from its siblings.

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

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

With no output schema, the description must convey the return shape, and it does ('per-criterion scores, findings and fixes'). For a zero-required-parameter read-only audit that is close to sufficient; only environmental prerequisites are unstated.

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

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

There is a single optional parameter with 100% schema description coverage, which already explains tabId and its default to the session target tab. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Scores how ready the page is for AI agents') and enumerates the exact criteria covered (accessibility tree, CLS, WebMCP tools, llms.txt), which separates it from general-purpose siblings like perf_metrics or devtools_issues. It does not name an alternative explicitly, but the scope 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?

Usage is only implied: an agent can infer it should run this to assess a page's agent-friendliness, but there is no statement of when to prefer it over perf_metrics or page_snapshot, no preconditions (page loaded, network available), 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?

readOnlyHint=false already tells the agent this tool mutates, so the create/remove mention is consistent but not additive. It omits whether removal is permanent, what happens when creating a duplicate URL, and whether search covers folders as well as entries — meaningful gaps for a 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?

A single sentence that front-loads the primary read operation and enumerates the mutations without waste. Nothing extraneous, though it could have spent one more clause on scope.

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 six parameters, a required action discriminator, and no output schema, the definition should indicate what search returns (list shape, limits) and what create/remove return. Those are missing, leaving the agent to discover result shapes empirically.

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% and each parameter already carries its own action binding and default. The description's parenthetical mapping of field to action merely restates the schema rather than adding syntax or constraints.

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 three specific verbs (searches, creates, removes) bound to one clear resource (bookmarks), and the action enum matches them. It is distinguishable from history_search by resource, though it never explicitly contrasts the two.

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

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

No statement of when to pick this over history_search or storage, and no prerequisites (e.g., signed-in state, folder existence). The action enum implies the modes, but selection guidance is absent.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-open-world), so the description need not restate them. It adds value by enumerating the returned signals, which matters because no output schema exists. Minor gap: it does not describe the disconnected/failure shape of the response.

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, no filler. The content report comes first and the call-to-action trigger follows, so the agent gets the essential routing hint at the end without wading through prose.

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?

Since there is no output schema, the description carries the burden of explaining the return payload, and it does so by listing the four signal categories. What's missing is how an unhealthy state is expressed (error vs. boolean field), a small but real gap for a diagnostic tool.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The empty schema with additionalProperties=false matches the description's claim that the call needs no arguments.

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?

Names a specific verb ('Reports') and enumerates the exact facts returned: extension connectivity, extension/browser versions, bridge port, and DevTools channel availability. Clearly distinct from siblings like page_info or devtools_context, which report page-level rather than bridge-level 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?

Gives an explicit trigger: 'Call this first when other tools report that the extension is not connected.' That is a concrete diagnostic entry point. It does not state when not to call it (e.g., during normal healthy operation), but for a status probe the guidance is sufficient.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, which correctly conveys that this does not mutate the page. The description adds that events are buffered, but never discloses that reading clears the buffer by default (only the schema says so) nor that unsubscribe exists — both are behavioral facts an agent should not have to infer from 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?

Two short sentences: the capability first, the prerequisite second. No filler and no repetition of the 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 5-param tool with no output schema, it covers the buffer model and the domain-enablement prerequisite, which is the critical setup knowledge. It stops short of describing the shape of the returned events or the unsubscribe path, leaving a small gap for an agent that must decide which action to pass.

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 defaults for clear, limit, tabId and the action enum are already documented. The description's only added value is illustrating the event-name pattern syntax ("Network.*", "Page.loadEventFired"), which marginally extends the schema's 'Event name or "Domain.*"'.

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: subscribes to raw DevTools Protocol events of a tab and reads the buffered events, with example event names. It is clearly differentiated from cdp_send (which sends commands and enables domains), though the third action, unsubscribe, is never reflected in the description.

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 prerequisite: enable the domain first with cdp_send if it is not already enabled. That is the main gotcha for CDP subscription. It does not distinguish subscribe from read from unsubscribe, nor say when to prefer this over higher-level siblings like network_requests or console_logs.

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

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

Annotations already mark it as non-read-only and open-world, and the description adds useful behavior beyond that: automatic routing through the full DevTools channel for domains unavailable to extensions, and the safeguard that disabling domains other tools rely on is ignored. It does not cover error behavior or permission requirements, but the added routing context is 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?

The definition is front-loaded with the core action and is only three sentences long. Each sentence adds relevant information, though the routing and domain-disabling details are slightly dense.

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 raw CDP command tool with no output schema, the description explains that it returns the raw result and clarifies routing and target behavior. It is largely complete given the rich schema and annotations, with only minor gaps around error handling and explicit alternative selection.

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 all six parameters are already documented. The description reinforces target selection for tab, iframe via frame ref, and child session id, but adds little beyond the schema's own 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 clear verb and resource: it sends any Chrome DevTools Protocol command to a tab, iframe, or child session and returns the raw result. This distinguishes it as a raw CDP escape hatch, though it does not explicitly contrast itself with sibling tools such as cdp_events or evaluate.

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 by “any Chrome DevTools Protocol command,” suggesting it is for arbitrary or low-level CDP calls rather than higher-level helpers. However, it does not explicitly say when to prefer this over sibling tools or when not to use it.

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

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

The description goes well beyond annotations by detailing real trusted mouse events, automatic scrolling into view, overlay warnings, and exactly what the tool returns (navigation, new tabs, dialogs, console errors). This gives the agent a clear picture of side effects and outcome reporting.

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 waste: action first, then behavioral safeguards, then return values. Front-loaded and appropriately sized.

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

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

For a browser click tool with no output schema and moderate complexity, the description covers the action, side effects, and return format comprehensively. Nothing essential for correct invocation is 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 coverage is 100%, so the schema already documents all seven parameters including enums and defaults. The description adds only high-level targeting context (ref vs. point) but no param-specific details beyond what the schema provides, making baseline 3 appropriate.

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

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

The description states a specific verb (clicks) and resource (element by ref or viewport point), making the action unambiguous. It does not explicitly name sibling tools like hover or drag to differentiate, but the distinction is implicit from the action itself.

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 by the action and the two targeting modes (ref vs. point), but there is no explicit guidance on when to choose click over alternatives such as hover or drag. No prerequisites or exclusions 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?

The annotations declare readOnlyHint=false and openWorldHint=false, so the agent knows writes are possible and the tool is not open-world. The description adds that content is plain text only, which is useful, but it does not disclose overwrite behavior, permission requirements, or error conditions.

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

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

A single, front-loaded sentence with zero waste. It states the action and the content format immediately.

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 and no output schema, the description is nearly complete. It could mention permissions or overwrite behavior, but the essential behavior is 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 the parameters are already documented in the schema. The description adds no syntax or format details beyond confirming plain-text handling, which is the expected baseline when 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 and resource: reading or writing the system clipboard. It is clear and unambiguous, and no sibling tool covers clipboard access, though it does not explicitly distinguish itself from 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?

Usage is implied by the read/write action enum and the plain-text limitation, but the description gives no explicit guidance on when to choose this tool or any prerequisites such as clipboard permissions or focus requirements.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description still adds real behavioral context: stack traces are attached to errors by default, output spans iframes and workers, and the buffer is retroactive ("as far as Chrome kept them"), which warns the agent that history is best-effort and bounded. It stops short of saying whether clearing happens by default or how the retention window behaves.

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 analogy that anchors the whole mental model, followed by the retention caveat. The em-dash enumeration is dense but every clause carries distinct information; 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 seven-parameter read tool with no output schema, the description does enough: it says what kinds of records come back, that stacks accompany errors, and that scope extends to frames and workers. Remaining gaps are minor — ordering of results, default tab resolution, and truncation semantics — and are largely covered by 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 all seven parameters (clear, limit, since, stack, tabId, levels, pattern) are already documented in the schema. The description only lightly echoes two of them (stack traces for errors, retained history implied by `since`) and adds no format or interaction detail such as how clear combines with limit.

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?

Specific verb and resource ("Reads the tab's console") with an explicit enumeration of what is captured: console.* calls, uncaught exceptions, promise rejections with stacks, and browser-side messages, scoped to page, iframes and workers. It is very clear what the tool returns, but it never names or contrasts a sibling — notably devtools_issues, which also surfaces violations/deprecations, and network_har/network_requests for network errors — so an agent must infer the boundary itself.

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 by the framing "like the DevTools Console panel" and by the breadth of captured message types, but there is no explicit when-to-use, when-not-to-use, or alternative routing. Nothing tells the agent whether to prefer this over devtools_issues for grouped browser issues or over evaluate for ad-hoc diagnostics.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description adds a meaningful caveat beyond them: JS coverage needs the full DevTools channel. No contradiction with the read-only hint, since it's a measurement session, not page mutation. Slightly more could be said about what a stopped session 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?

Three tight sentences, front-loaded with the purpose followed by the actionable workflow and the one important constraint. 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?

No output schema exists, but the limit parameter ('show at most this many files') implies a ranked file list return, which is adequate. The start/exercise/stop workflow plus the JS caveat give an agent enough to invoke it correctly; only return-shape detail is left implicit.

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 limit, tabId, types, action, and reload are all documented in the schema. The description's start/stop workflow maps to the action parameter but adds no syntax or format detail beyond that. Baseline 3 is appropriate.

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

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

States a specific verb and resource: measures unused CSS and JavaScript per file, explicitly analogized to the DevTools Coverage panel. A distinct purpose from siblings like perf_metrics/perf_trace, though it doesn't name those alternatives to sharpen 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?

Gives an explicit workflow: call action 'start', exercise the page, then 'stop'. It also flags a precondition – JavaScript coverage requires the full DevTools channel while CSS always works. Clear usage context, though it doesn't contrast with sibling 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 readOnlyHint=true and openWorldHint=false already in annotations, the safety profile is largely covered, and the description usefully discloses what is returned. However, it does not mention that clearInbox removes inbox items, which is a side effect that sits awkwardly against the read-only annotation and the description should have surfaced it.

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

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

A single well-formed sentence, front-loaded with the activating condition and then the two return categories. No filler, though the parenthetical field lists make it dense and slightly harder to scan than a short bulleted structure would be.

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 carries the return-shape burden and does name the key returned fields (selector, HTML, ref) and the inbox item types. The main omission is the clearInbox side effect, which leaves a behavioral gap for a two-parameter tool.

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

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

Schema coverage is 100%, so both tabId and clearInbox are documented in the schema; baseline is 3. The description reinforces the semantics of the returned inbox items ('with notes', elements or network requests) but adds nothing about tabId targeting or the destructive implication of clearInbox beyond what the schema says.

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

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

The description gives a specific verb and two clearly enumerated resources: the element currently selected in the Elements panel (selector, HTML, ref) and the items the user sent from the 'Kyte WebMCP' DevTools panel. It's clear what comes back, though it never names dom_inspect or devtools_reveal as the sibling alternatives, so differentiation relies on the reader's inference.

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 clause 'When the user has DevTools open on the tab' states a precondition, which is useful context for invoking it. But it offers no when-not guidance and never routes the agent to alternatives like dom_inspect for programmatic inspection, so the selection logic is only implied by the environment condition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful scope detail that results come from the Issues panel rather than the console, but says nothing about ordering, severity, pagination, or what the 'clear' side effect means for the page state.

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

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

One sentence, front-loaded with the verb and source of truth, with the category enumeration serving the purpose of scope definition. 'and more' is slightly vague but does not waste space.

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 carries the burden of indicating what comes back; it never says whether results include severity, counts, or ordering. For a read-only list tool with rich annotations this is adequate but leaves a real gap about the response shape.

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 three parameters (clear, limit, tabId) including defaults. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Lists') and a precise resource ('problems the DevTools Issues panel detected on the page'), then enumerates concrete issue classes (CORS, mixed content, CSP, deprecated APIs) that make the tool's scope tangible. It doesn't explicitly contrast itself with nearby siblings like console_logs or network_requests, 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 category list implies when the tool is useful (diagnosing page-level browser warnings rather than console output), but there is no explicit 'use this instead of X' routing and no stated prerequisites or exclusions. Usage is inferable rather than guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely useful context by naming the target panel and the DevTools-open prerequisite that will cause failure. It doesn't say what happens when DevTools is closed (error vs no-op) or whether navigation in the panel replaces current DevTools state.

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

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

One dense sentence with a colon-delimited structure that front-loads the action and then enumerates the two modes, plus a short prerequisite clause. No filler sentences.

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-required-parameter mutation-of-UI tool with no output schema, the description covers the modes and the prerequisite well. The notable omission is that nothing says a call with no arguments is invalid/meaningless, which an agent could easily attempt given the empty required list.

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 raw parameter meanings are already documented; the description earns extra credit by explaining the combinatorial pairing — ref/selector belong to the Elements mode, url+line to the Sources mode. It does not state that at least one mode's parameters must be supplied, which is the main semantic gap.

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

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

States a concrete verb ('Shows') and two well-defined resources/modes: an element in the Elements panel or a source file in the Sources panel, each with the parameters that select it. It's clear what the tool does, though it doesn't explicitly contrast itself with neighbouring inspection tools like dom_inspect or devtools_context.

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 the key prerequisite ('Requires DevTools to be open on the tab') and clarifies that the effect is user-visible, but gives no guidance on when to prefer this over dom_inspect, devtools_context, or evaluate for similar inspection goals. Usage is implied by the two modes rather than stated as selection 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?

Annotations declare readOnlyHint=false and openWorldHint=false, so the mutation profile is already covered. The description adds useful context by naming the dialog types and clarifying that prompt input happens before accepting, but omits behavior on error (no dialog open) and whether the call blocks or waits for a dialog to appear.

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

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

A single front-loaded sentence with the action verb first and the qualifying scope ('currently open in the tab') immediately after. Zero 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 three-parameter tool with fully documented schema and no output schema, the description covers what would be returned (nothing, conceptually) and how the action applies. The only material gap is the no-dialog-open case, which is a modest omission.

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 marginal value by tying the prompt dialog type to the promptText parameter's purpose. It does not restate the tabId default, which the schema already handles.

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 (accepts or dismisses) and resource (the JavaScript dialog currently open in the tab), and enumerates the dialog types handled (alert, confirm, prompt, beforeunload). No sibling tool covers dialog handling, so it is clearly distinguishable from click/press_key/evaluate.

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 by 'currently open in the tab' – the agent infers it should call this only when a dialog is blocking the page. However, it never states what to do when no dialog is present, nor points to any alternative (e.g., pressing Enter or navigating away), so guidance is present but 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing the breadth and shape of what is returned (matched rules with stylesheet and line, inherited styles, listeners, a11y). It stops short of noting cost/size implications of large element trees or the default section set.

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 sentence, front-loaded with the verb and the DevTools analogy, then a compact enumeration. No filler and no restatement of the name/title.

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

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

With no output schema, the description must carry the return-value burden, and it does so thoroughly. Minor gaps remain: no note that unlisted sections are omitted by default or that inspection can be expensive on large/complex nodes.

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

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

Schema coverage is 100%, so every parameter is already documented, and the description adds no syntax or constraint detail beyond echoing sections like computed styles. Baseline 3 is appropriate.

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

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

States a specific verb (inspects) and resource (one element), and enumerates the returned sections with a helpful DevTools Elements-panel analogy. It distinguishes itself from siblings like page_snapshot/find indirectly (those produce refs, this consumes them), but never names an alternative outright.

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: on-demand, single-element deep inspection rather than whole-page capture. There is no explicit when-to-use/when-not guidance and no mention of choosing between ref and selector, which is the only real decision an agent faces here.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent knows this is a mutating, network-touching tool. The description adds a real behavioral clue by exposing a separate 'wait' action, implying downloads are asynchronous and may need polling. It still omits where files land, whether 'download' returns an id required by 'wait'/'cancel', and whether the call blocks.

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

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

A single front-loaded sentence that defines the resource first and then the action vocabulary, with no filler. It is dense and readable, though the inline action glossary is slightly run-on.

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

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

For a 6-parameter, mutation-capable tool with no output schema, the description leaves important workflow facts unstated: the download destination folder, what 'download' returns, and how ids for 'wait'/'cancel' are obtained. Adequate for identifying the tool, thin for calling it correctly in sequence.

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% and every parameter is already tagged with its owning action (id for wait/cancel, url for download, etc.), so the schema does the heavy lifting. The description's action list only loosely mirrors that mapping and adds no format or constraint details beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('Manages browser downloads') and enumerates all four action modes, so an agent can tell what the tool covers without opening the schema. It doesn't differentiate itself from nearby siblings like upload_file or pdf_save, which keeps it 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?

Mapping each action to its meaning ('wait' waits for a download to finish, 'cancel' cancels one) implies when each mode applies, which is useful. But there is no explicit guidance on sequencing (e.g. that 'download' is async and 'wait' is needed afterward) and no mention of when to prefer this over siblings such as pdf_save.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation profile is covered. The description adds real value by disclosing that it emits genuine mouse events and handles both mouse-driven and HTML5 drag semantics, which no structured field conveys. It stops short of failure behavior, event sequencing, or timing, so it is useful but not rich.

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 sentence, front-loaded with the action and the endpoint duality, with no filler. Every clause (real mouse events, mouse-driven vs HTML5) carries information an agent cannot get elsewhere.

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

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

There is no output schema, so the description should convey what a successful or failed drag yields and roughly how long it takes. It covers the mechanics competently but omits outcome reporting and error conditions, leaving a gap for a mutating, open-world interaction tool.

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

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

Schema description coverage is 100%, so both coordinate objects, both refs, and tabId are already documented. The description only restates the two endpoint modalities ('element or point') without adding format, precedence, or conflict-handling rules between coordinates and refs. Baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb (drags) and the two endpoint forms (element or point), plus the mechanism ('real mouse events') and the drag-and-drop flavors supported. An agent can distinguish this from click/hover without opening the schema, though siblings are never named explicitly.

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

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

No guidance on when to prefer drag over hover/click or on which task shapes require it. The fromRef/from-vs-to/toRef choice is only documented in the schema, not framed as a usage rule, so the description leaves all routing decisions 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?

Annotations declare this is a state-changing but idempotent, non-open-world operation; the description adds two non-obvious traits the annotations cannot convey: settings accumulate across calls rather than replacing prior state, and emulation is torn down when the session ends. That accumulation/lifecycle detail is exactly the kind of context an agent needs to avoid surprise.

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: capability list first, then the accumulation rule, then cleanup. No filler, and the most consequential behavioral fact (state persists across calls) is placed before the more obvious session-end note.

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 21-parameter, zero-required, no-output-schema tool, the description covers purpose, statefulness, and teardown, and the annotations cover safety profile. It stops short of explaining how presets interact with individually supplied width/height or that reset=true supersedes other args in the same 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 coverage is 100%, so the baseline is 3, but the description earns a bump by explaining the reset parameter's full effect ('restores everything') and the preset-vs-custom viewport relationship, which the schema only states piecewise. It doesn't document enum values (network presets, device names) beyond what the schema already lists.

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

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

Opens with a specific verb ('Emulates') and enumerates the exact resources it controls — viewport, user agent, locale, timezone, geolocation, color scheme, motion, network, CPU, vision deficiency. An agent can tell this is the emulation switchboard and distinguish it from siblings like devtools_context or cdp_send 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 description implies usage (emulating a device/environment) but never states when to reach for this versus alternatives such as cdp_send or devtools_context, nor any prerequisites like needing an active tab. The tabId default note lives only in the schema, not the description.

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

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

With annotations declaring readOnlyHint=false and openWorldHint=true, the description adds valuable behavioral context: promises are awaited, DOM nodes/functions/cyclic objects are described rather than causing failures, and isolated worlds cannot see page globals. It does not contradict annotations and meaningfully supplements them.

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 four tight sentences, front-loaded with the primary purpose and followed by the most decision-relevant details. There is 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?

For an 8-parameter tool with no output schema and no required params, the description covers return format, unserializable value handling, execution worlds, and frame selection. Remaining details like timeout and userGesture are adequately covered by the schema, so the description is nearly complete.

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

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

Schema coverage is already 100%, setting the baseline at 3, but the description adds semantic meaning beyond the schema: the expression-vs-function distinction, the behavioral implication of world='isolated', and the frame ref rule. This helps an agent choose parameter values correctly.

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 ('Runs JavaScript in the page and returns the result as JSON') and clearly distinguishes the tool from siblings like cdp_send or console_logs. An agent can immediately tell this is the direct page-context evaluation tool.

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 by explaining expression vs function modes and frame/world selection, but it never states when not to use it or which siblings are alternatives. Usage is inferable but not explicitly routed.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description must carry behavioral weight; it usefully explains per-element value coercion (text/textarea vs checkbox/radio/switch vs select). It does not say whether filling is atomic on failure, whether change/blur events fire, or what gets reported back — significant gaps for a mutating tool with no output 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 tight sentences, zero filler, and the batch scope is front-loaded ahead of the value-format rules. Nothing repeats the schema verbatim.

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?

Covers purpose and value typing, but omits failure/partial-application behavior, the need for refs from page_snapshot (only in schema), and any statement about return values. With no output schema, some of that burden lands on the description and is unaddressed.

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

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

Schema coverage is 100%, which sets a baseline of 3, but the description goes beyond it by specifying the accepted value grammar per element type ("true"/"false" for checkboxes, label-or-value for selects). That is real semantic guidance the schema's generic 'Value to set.' does not provide.

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 clear verb+resource ('Fills several form fields') and emphasizes batch semantics ('in one call'), which implicitly distinguishes it from the sibling `type` (single-field) and `select_option` tools. No sibling is named explicitly, 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?

Batching is implied by 'several form fields in one call', but the description never says when to prefer this over `type`, `press_key`, or `select_option`, nor what to do if a ref is stale. Usage must be inferred from the word 'several'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it traverses iframes and shadow DOM, and returns refs carrying role, name, and position — the latter is important since there is no output schema.

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

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

A single dense sentence with the action, supported strategies, depth of traversal, and return value, all front-loaded. Nothing redundant or 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?

With no output schema, the description compensates by describing the returned refs and their fields. What remains missing for a 7-optional-parameter tool is combination/precedence semantics and the no-match case, which an agent would want before calling.

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

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

Schema description coverage is 100%, so each parameter (name, role, text, limit, tabId, xpath, selector) is already documented with defaults. The description adds no syntax or precedence guidance, such as whether strategies are ANDed or ORed when multiple are supplied — the one gap the schema does not fill.

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 ('Finds elements') plus the full set of matching strategies (visible text, CSS selector, XPath, accessible role/name) and the return shape (refs with role, name, position). An agent can distinguish this from siblings like page_snapshot or dom_inspect because the description names the match modes and the ref-based output.

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: 'finds elements' suggests you call it before acting on an element, but the description never says when to prefer it over page_snapshot, page_read, or dom_inspect, nor does it state exclusions or prerequisites (e.g., needing an active tab).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds no behavioral context beyond the name: nothing on result ordering (recency?), whether an empty call returns everything, or pagination/truncation behavior at maxResults.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity comes partly from omitting useful detail rather than from tight editing.

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

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

For a simple read-only, zero-required-param search with a fully described schema and no output schema, the description is minimally sufficient. Missing are ordering guarantees and how results are capped, which an agent would want before paging or assembling a picture of history.

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 each parameter (text, startTime, maxResults) fully documented including units and defaults. The description merely restates the filter dimensions, adding no semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (searches) and resource (browsing history) plus the filtering facets (text, time range), which distinguishes it from resource-adjacent siblings like bookmarks and downloads. It does not explicitly call out those siblings, 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?

Usage is implied by the purpose — a read-only lookup over history — but there is no explicit when-to-use or when-not-to-use guidance, and no pointer to an alternative sibling when the target is a bookmark or download instead.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=false; the description adds the useful behavioral fact that hovering can open menus/tooltips. However, it does not say how the input is dispatched (pointer/mouse event sequence vs single move), whether the pointer position persists for a subsequent click, or whether it waits for the revealed UI to settle — all relevant for a mutation-flagged 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?

A single sentence, front-loaded with the action, with the two targeting modes and the expected outcome packed in and no filler. Every clause carries information.

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

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

With no output schema and four optional parameters, the description covers the target selection but leaves open what the tool reports back (nothing? coordinates hovered? revealed elements?) and the post-hover state, which matters for chaining a click after a hover-revealed menu. Adequate but with clear gaps for a UI-interaction primitive.

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 3 is the baseline, but the description adds real meaning by framing 'ref' and 'x/y' as two alternative targeting modes (element vs viewport point), which the schema's flat property list does not convey. It still omits precedence when both ref and x/y are supplied, which is why it is not a 5.

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

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

States a concrete verb (moves the mouse over) plus the resource/targeting modes (element by ref or viewport point), and notes the observable effect (hover menus, tooltips). That distinguishes it from click, drag, and press_key without naming them, but it never explicitly routes away from those siblings, 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 by the phrase 'triggering hover menus and tooltips' — an agent can infer 'use this to reveal hover-only UI,' but there is no explicit when-to-use, no when-not (e.g., for activation use click), and no prerequisite or sequencing guidance such as whether to call wait_for afterward for lazily rendered menus.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so the description need not restate safety. It adds real value instead: the return payload is enumerated, it discloses partial-result behavior ('codec and bitrate when they can be determined'), and it flags a dependency ('uses the full DevTools channel when available') that hints at capability-dependent results.

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 substantive return-field list; nearly every clause carries information. The dense comma-separated enumeration is slightly hard to scan 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?

With no output schema, the description responsibly enumerates return fields, and the DevTools-channel note explains variability in results. The remaining gap is when-to-use versus alternative diagnostic tools, which the description leaves entirely to inference.

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

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

Schema description coverage is 100% and all three parameters (tabId, video, sampleMs) are fully documented there, so the baseline applies. The description adds only an indirect hint that frame rate is measured, without explaining defaults, the video ref format, or the sampling window.

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?

Names a specific verb (inspect) and resource (media player) and enumerates the exact telemetry returned (resolution, dropped frames, buffered ranges, ready/network state, errors, events). It is distinguishable from video_control and video_list by being a read-only diagnostic, though it never names those siblings explicitly.

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

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

The DevTools Media panel analogy implies the usage context (debugging playback health), but there is no explicit statement of when to prefer this over perf_metrics, perf_trace, or video_control, nor any when-not guidance. The agent must infer the routing 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?

Annotations declare readOnlyHint=true, but the description says snapshot is saved as a .heapsnapshot file and that gc can collect garbage first. Saving a file and forcing GC are side effects, which contradicts the readOnly annotation.

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

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

The description is compact with no filler, but it is a single telegraphic fragment with awkward quoted action labels and it begins with action details rather than a clear tool-level summary.

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

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

With no output schema, the description does enough by listing what counters returns and what snapshot produces. It could be stronger by stating snapshot output shape or failure behavior when the DevTools channel is unavailable, but it covers the essential call 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 coverage is 100%, and the description still adds action-specific meaning beyond the enum labels: counters lists the exact metrics, snapshot explains the heapsnapshot output and summary, and gc is described as defaulting to true for snapshot. tabId is not expanded, but the schema already documents 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 names two concrete actions and specifies what each does: counters measures heap size, DOM nodes, documents, frames and event listeners; snapshot captures a heapsnapshot and summarizes object classes and detached DOM nodes. It is clear, but it does not distinguish the tool from nearby siblings such as perf_metrics, dom_inspect, or coverage.

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 explicit usage constraint is that snapshot needs the full DevTools channel. There is no explicit when-to-use guidance for choosing counters versus snapshot, nor any comparison to alternative diagnostic siblings.

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 only readOnlyHint=false and openWorldHint=true declared, the description usefully adds the failure mode ('fails with the network error when the page cannot be loaded') and the post-redirect return values. It omits meaningful side effects an agent should know: that navigation discards current page state, that in-flight requests/dialogs may be aborted, and how the timeout behaves on a hang.

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 with the primary action front-loaded, then return contract, then error contract – a clean priority order with 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?

No output schema exists, and the description compensates by naming exactly what comes back (final URL after redirects, title, HTTP status) and the error condition. Combined with a fully annotated schema, an agent has everything needed to call it and interpret the result.

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 url/action mutual exclusion, timeoutMs, waitUntil and ignoreCache are already fully documented in the schema. The description's only additive nuance is 'final URL (after redirects)', which concerns the return value rather than the parameters; baseline 3 applies.

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

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

States a specific verb and resource ('Navigates the tab to a URL') plus the alternative modes (back/forward/reload), so the core action is unmistakable. It does not, however, distinguish itself from the sibling tab_open or explain how it relates to wait_for, leaving the boundary between 'navigate existing tab' and 'open new tab' implicit.

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

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

The description implies usage through the url-vs-action split, but never states when an agent should pick this over tab_open, tab_select, or a follow-up wait_for. There is no explicit when-not guidance or prerequisite (a tab must exist / be selected) called out in the description itself.

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

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

Beyond the annotations, it discloses the output medium (a file on disk), the default destination behavior, that response bodies are opt-in, and that the return value is a path. It does not warn about file size or capture-window limits when bodies are included, which is the remaining 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?

One sentence, front-loaded with the action and artifact, with the optional flag as a parenthetical. Nothing is wasted or repeated.

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

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

For a zero-required-parameter export tool with no output schema, telling the agent it returns a path is the key missing piece and it is present. Only a note on capture scope (which requests are 'captured') and the interaction with network_requests is absent.

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 tabId, bodies, and savePath are already fully documented in the schema. The description's mentions of 'optionally with response bodies' and 'returns its path' merely restate schema content, so baseline 3 applies.

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

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

Names a specific verb and resource (exports captured tab requests) plus the concrete artifact format (HAR 1.2) and that a path is returned. It is distinguishable from siblings like network_requests or perf_trace by the word 'HAR', but it never explicitly contrasts with them.

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

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

Usage is only implied: an agent can infer this is the tool for producing a HAR file after traffic has been captured. There is no statement of when to prefer it over network_requests/network_request, nor any prerequisite such as needing a session tab.

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

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

The annotations already mark this as a non-read-only, open-world tool, so the main added behavioral detail is that rules are removed when the session ends. That is useful lifecycle context, but the description does not explain rule precedence, immediate application, or what clear/list return.

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

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

The description is two sentences, front-loaded with the core operation and followed by the key lifecycle constraint. There is no filler, and every sentence carries useful 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?

The description covers the main purpose and session-bound lifetime, which suits a moderately complex, schema-rich tool. It stops short of explaining the clear action, list output, or practical usage relative to sibling network tools, so it is 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 schema already documents all nine parameters thoroughly. The description adds only high-level mapping to block/respond/rewrite behavior and does not explain clear, id, tabId, method, urlPattern, resourceType, or nested response fields 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 states a specific resource and set of operations: interception rules for a tab, including blocking, fake responses, and header rewriting. It is clear enough to distinguish from general network inspection siblings, but it does not explicitly name alternatives such as network_requests or network_har.

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 by the listed capabilities: block matching requests, return a fake response, or rewrite headers. However, the description does not explicitly say when to choose this tool over network_request, network_requests, or network_har, and it gives no exclusions or prerequisites.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior, namely that large or binary bodies are diverted to a file rather than returned inline, and that WebSocket frames and initiator stacks are included in the payload. It omits failure behavior for unknown/expired request ids and any caveats about payload size, so it stops 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?

A single front-loaded sentence that enumerates return contents with one clarifying parenthetical; every clause carries information and nothing is redundant with the annotations.

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

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

With no output schema, the description effectively serves as one by listing every returned section, which is exactly what an agent needs before calling. Missing are the error case (stale/unknown request id) and explicit linkage to network_requests for obtaining the id, minor but real 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, but the description adds real meaning by explaining that the response body may be returned as text or written to a file when binary/large, which clarifies the interplay of the body, savePath, and maxBodyChars parameters. It does not explain id format or tabId scoping, which the schema carries on its own.

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 resource ('one request') and enumerates exactly what is retrieved (headers, bodies, timings, security, initiator stack, WebSocket frames), which makes it clearly distinct from the list-style sibling network_requests. It never states the verb (fetch/retrieve) or explicitly routes the agent from network_requests, so it falls short of a 5.

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

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

The description gives no when-to-use, when-not-to-use, or alternative guidance; it never says to call network_requests first to get an id, or when to prefer network_har for bulk data. Usage must be inferred entirely from the name and schema.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely new behavior about the ring buffer's temporal scope and how to recover missing entries via reload. It also implies the buffer can be cleared after reading (via the clear param) without spelling out consequences.

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, front-loaded with what the tool returns, followed by filtering and then the critical capture-window caveat. No filler text; each sentence carries distinct 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?

No output schema exists, and the description compensates by enumerating the returned fields (id, method, URL, status, type, size, duration, cache, initiator). Combined with the buffer caveat and the filter list, an agent has everything needed to call 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 coverage is 100%, so the baseline would be 3, but the description adds value by naming the filter dimensions (URL pattern, resource type, method, status, failures) and confirming 'failures' as a usable status filter. It does not clarify defaults for limit or the all/main-frame-navigation distinction beyond what the schema states.

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 (lists the tab's requests) and enumerates the returned fields, anchoring the mental model to the DevTools Network panel. The 'lists ... requests' phrasing plus field list makes it distinguishable from the HAR-export and single-request siblings even without naming 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?

Explains the filter dimensions available for narrowing results and states a real usage constraint: requests made before the agent started watching are unavailable and a reload is needed to capture them. It does not explicitly route to alternatives such as network_har or network_request, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description then adds genuinely new behavioral detail by enumerating what is actually collected, notably that the frame tree includes cross-origin iframes and that main-document security details are reported. It does not mention that the values are a point-in-time snapshot or how missing fields behave, keeping it below 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?

One front-loaded sentence with a dense but purposeful field list; no filler, no restatement of the title. The most important identifiers (URL, title, load state) come first.

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

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

With no output schema, the description must carry the return-shape burden and it does so by enumerating every reported field group. It is slightly incomplete on edge cases (fields absent on non-page targets, snapshot semantics), but an agent has enough to decide to call 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?

Schema coverage is 100% and the single tabId parameter is fully documented in the schema, including the default-to-session-tab behavior and a pointer to tab_select. The description says nothing about parameters, which is acceptable given the schema does the work, so the baseline 3 applies.

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

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

The description names a specific verb ('Returns') and enumerates the exact metadata resource: URL, title, load state, language, viewport, scroll, document size, frame tree, security details. This clearly separates it from page_snapshot/page_read (content) and browser_status (browser-level). It stops short of a 5 because it never explicitly contrasts itself with those nearest 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?

No indication of when to call this versus page_snapshot, dom_inspect, or browser_status, and no prerequisites or exclusions. The agent must infer from the return-field list that this is a lightweight metadata probe rather than a content read.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that long content is paginated via offset/maxChars, which is useful behavioral context, but it doesn't mention whether truncation is signaled in the result or how pagination terminates.

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 waste; the return format is front-loaded and pagination is mentioned last as a secondary 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 read-only extraction tool with no output schema and fully documented parameters, the description covers what comes back and the pagination mechanism. Minor gap: no note on how a truncated result is indicated, which matters when paginating.

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 all 7 parameters are already documented with defaults and semantics. The description only restates the pagination pair (offset/maxChars) and adds no new parameter meaning, so baseline 3 applies.

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

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

States a specific verb (returns), resource (page or one element), and output format (Markdown), plus enumerates what's included: headings, paragraphs, lists, links, tables, code. Sibling differentiation from page_snapshot/find is only implicit via the ref parameter's schema note, not stated in the description itself.

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 by 'readable content' — an agent can infer this is for extracting readable text rather than structure or raw HTML. But there is no explicit when-to-use vs page_snapshot, evaluate, or dom_inspect, and no guidance on when to prefer selector vs ref.

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

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

Annotations already carry readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real behavioral context: coverage extends into cross-origin iframes and shadow DOM, output is compact, and refs are stable. Truncation and viewport filtering behavior live in the schema rather than the prose, leaving a small 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, front-loaded with what the tool returns and what makes it distinctive (Chrome-native tree, cross-origin/shadow coverage), then the ref mechanism, then the routing advice. No sentence is 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?

A read-only, no-required-param inspection tool with a fully documented schema and no output schema; the description supplies the qualitative return shape (compact tree of roles/names/states/values) and the ref handle an agent needs to act on the result. Nothing material is missing 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 baseline is 3; the description earns above that by explaining what a ref is ([ref=e12]), that refs are stable, and that they are the currency of the click/type/fill_form family — which is exactly the semantics the `root` parameter depends on.

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?

A specific verb and resource — returns the page as a Chrome-built accessibility tree — with the exact content enumerated (roles, names, states, values), plus scope details (cross-origin iframes, shadow DOM). The sibling names page_read, dom_inspect and screenshot are effectively distinguished by the 'prefer over screenshots for structure' line and the tree/ref framing.

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 says to prefer this over screenshots for understanding structure, and explains the downstream workflow (refs feed click, type, fill_form, screenshot, dom_inspect). It stops short of stating when to choose page_read or dom_inspect instead, so the sibling routing is one notch below complete.

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

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

Annotations give readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral fact beyond that — that the tool returns a file path — but says nothing about whether the existing default-path file is overwritten, whether it waits for the page to finish loading, or whether it captures the full scrollable page. Note a mild tension with readOnlyHint=true, since a PDF is written to disk, though creating a new artifact rather than mutating page state is a defensible reading.

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 sentence with zero filler, with the action and the return value front-loaded. It is efficient but so terse that it does no structuring work — there is no grouping of the six formatting options or the output-path behavior.

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 six all-optional, fully schema-documented parameters and no output schema, the description's statement of the return value is the one thing that must be there and it is. However, for a tool that writes a file to disk it omits where the default output folder is (left to the schema), overwrite behavior, and whether the capture includes the full page — gaps that matter 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%, with defaults, ranges, and the sole enum all documented in the input schema, so the baseline of 3 applies. The description contributes no parameter information of its own — no mention of paper size, scale, orientation, background printing, or the tabId/savePath interaction.

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?

Specific verb and resource: 'Prints the page to a PDF file and returns its path.' An agent can distinguish this from screenshot/downloads because the output medium (PDF) and the return value (path) are stated. It stops short of naming a sibling it is explicitly not, so it lands at 4 rather than 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?

There is no when-to-use/when-not guidance and no alternatives named — nothing tells the agent to prefer this over `screenshot`, `downloads`, or `page_snapshot` when the goal is capturing page content. The action is inferable from the description, but no usage context or prerequisites are supplied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by naming exactly which metrics are captured, including the LCP element and shifting elements for CLS, but says nothing about whether measuring forces layout/reflow, how long it takes, or whether values reflect load-time or current state.

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

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

One dense sentence, front-loaded with the primary purpose (Core Web Vitals) before the secondary runtime metrics. The parenthetical lists are long but each item carries information; nothing is redundant.

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

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

With no output schema and low complexity, the description covers what is measured but not how results are returned (units, structure, whether element/attribution data is nested). For a metrics tool with no output contract, at least a hint of the return shape would help.

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

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

There is a single optional parameter with 100% schema coverage, and the schema already explains that tabId defaults to the session target tab. The description adds no parameter-level meaning at all, so the baseline of 3 applies.

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

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

A specific verb ("Measures") plus enumerated resources (LCP, CLS, INP, FCP, TTFB, JS heap, DOM nodes, layouts, style recalcs, script time) makes the purpose unambiguous. It does not, however, distinguish itself from close siblings like perf_trace, memory, or coverage, which overlap on heap/timing data.

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 when-to-use guidance, no exclusions, and never names an alternative such as perf_trace (detailed tracing) or memory (heap inspection). An agent must infer the choice from the name 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?

The description is unusually rich about outputs (long tasks, TBT, main-thread breakdown, render-blocking requests, LCP, CLS, slowest scripts) and flags that recording can reload the page, with reload defaulting to true for 'run'. That default page reload, plus writing a .json file to disk, sits in tension with readOnlyHint=true, which tells an agent the call has no side effects; an agent trusting the annotation could reload a page with unsaved form state.

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

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

Two dense sentences, front-loaded with what the tool does and then what it returns; nothing is padding. The parenthetical '(open it in DevTools > Performance)' is genuinely useful, though the second sentence could have been folded in more tightly.

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

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

With no output schema, the description carries the burden of describing return values and does so thoroughly, and it documents the reload/duration interaction that the schema only hints at. What is missing is roughly how long a manual start/stop session can run and any permission or session-target constraints.

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 all six parameters are already documented, which sets the baseline at 3. The description adds a little beyond the schema by restating the run/start/stop semantics and the duration behavior ('or until load + 3 s when reloading'), but it does not explain savePath, cpuProfile or tabId defaults any further.

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 ('Records a performance trace like the DevTools Performance panel'), and spells out what it produces: a saved .json trace plus an analysis. It is clear what the tool does, but it never names the sibling that overlaps most (perf_metrics) or explains the boundary, so differentiation is implicit rather than explicit.

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

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

It explains the internal modes well ('start'/'stop' for manual recording, 'run' to record for durationMs), which is genuine usage guidance. However, it gives no guidance on when to reach for perf_trace instead of perf_metrics, coverage, network_har or console_logs, all of which sit in the same diagnostic space, so the alternative-selection question is left 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?

Annotations already declare this is not read-only and acts on an open world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — keys are sent to the currently focused element, with no selector targeting — but does not mention what happens if nothing is focused, whether events bubble/native, or the repeat behavior.

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

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

A single front-loaded sentence with the examples doing the heavy lifting and no wasted words. Well sized for a three-parameter keyboard tool.

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, and the three parameters are fully documented in the schema, so the description only needs to cover selection and behavior. It covers key syntax and the focus requirement but omits the fallback behavior when no element is focused and the repeat/tab-targeting implications.

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 earns a bump by illustrating the key-naming convention ('Enter', 'Escape', 'Control+A', 'Shift+Tab', 'ArrowDown'), which clarifies modifier joining and named-key spelling beyond the schema's terse 'joined with +' note.

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 ('Presses a key or key combination') and gives concrete examples of the input format. It does not explicitly differentiate itself from the sibling `type` tool (text entry) or `click`, which is the main remaining ambiguity.

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

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

The phrase 'on the focused element' implies the precondition that an element must already have focus, which is useful implied usage. However, there is no explicit when-to-use/when-not guidance and no mention of the alternative `type` tool for entering text, leaving the agent to infer the boundary.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, and the description adds genuinely new behavior: images are downscaled to maxWidth for token economy, savePath swaps the return channel from image content to a file write, annotate overlays numbered ref boxes, and it works on background tabs. Those are exactly the traits an agent needs that no structured field conveys.

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

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

Four short sentences, front-loaded with the primary purpose, then the annotate mode, then the cost/return controls. Every clause carries information an agent would otherwise have to infer; nothing is repeated from the schema verbatim.

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 8 optional params, 100% schema coverage, no output schema, and safety already covered by annotations, the description closes the remaining gaps: it explains the annotate workflow, the two return modes (inline image vs saved file), token cost behavior, and background-tab support. Nothing needed to invoke it correctly is 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 coverage is 100%, so the baseline is 3; the description earns above that by explaining the intent behind annotate (Set-of-Mark overlay for pointing), maxWidth (token-saving downscale), and savePath (file instead of returned image) rather than just restating types. It does not add detail on format/quality tradeoffs already covered by 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?

Names a concrete verb+resource ('Captures') and enumerates the three capture scopes (viewport, full page, one element), which maps directly onto fullPage/ref/neither. The Set-of-Mark annotation behavior and 'works on background tabs' clause further separate it from the DOM-oriented siblings like page_snapshot and page_read.

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 clear situational guidance inside the sentence: use annotate=true when you need to point at elements, use savePath when you want a file instead of an inline image. It never explicitly routes away from an alternative (e.g. pdf_save or page_snapshot when refs are needed), so no exclusions are stated, but the conditions for each mode are unambiguous.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries most of the burden. It adds genuinely useful behavioral context: scrolling is performed through real mouse-wheel events (not synthetic DOM manipulation), and a documented background-tab caveat explains the tool's raison d'être. It does not state what happens when conflicting modes are supplied, which is the remaining 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?

Single sentence, front-loaded with the primary verb and modes, with the background-tab rationale tucked into a parenthetical. It's dense but every clause contributes; the nested parenthetical is mildly hard to parse, keeping it off a 5.

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 7 all-optional parameters, no output schema, and three mutually exclusive operating modes, the description should state how modes interact and what is returned (scroll offset, success/failure, element-not-found behavior). It covers the modes but not their interaction or outcome, leaving the agent to guess when the call silently does nothing.

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 baseline is 3. The description earns above baseline by conveying the combination rules the schema cannot express: ref selects scroll-into-view, x/y selects element-under-point, direction/amount selects wheel scrolling. It still leaves precedence between modes (e.g., ref plus direction) unstated.

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

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

States a specific verb (scrolls) and enumerates the three distinct modes: element into view via ref, page/element-under-point via direction/amount, plus toEdge. No sibling tool overlaps with scrolling, so distinguishing is unnecessary, but the multi-mode enumeration makes the tool's scope concrete.

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

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

The parenthetical about background tabs states the key selection condition: use this rather than injected script because Chrome ignores synthetic wheel events in background tabs. It also implies ref-mode vs point-mode selection. It stops short of explicit exclusion rules (e.g., when to prefer `evaluate` or `navigate` instead).

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this mutates page state. The description adds only that multiple options may be selected; it does not say whether existing selections are replaced or appended, whether change events fire, or what happens when a label matches nothing.

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 sentence with zero filler, front-loaded with the verb and resource. It is appropriately sized for a simple tool, though it leaves room that could have carried a clause about selection semantics.

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

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

No output schema exists, and all parameters are schema-documented, so the basics are covered. For a state-mutating browser tool, however, the definition omits failure behavior for unmatched labels/values and the effect on pre-existing selections — details an agent needs to call 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 coverage is 100%, so all three parameters are already documented, including the ref format and tabId default. The description's 'by visible label or value' does add useful meaning to the values array beyond the schema's brief 'Option label or value', but only marginally.

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 ('Selects one or more options of a <select> element') with a clear scoping mechanism (visible label or value). It is distinguishable from click/fill_form by the <select> element reference, though it never names a sibling 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?

Usage is implied by the '<select> element' constraint, which lets an agent infer it should be preferred over generic fill_form or click for dropdowns, but no when/when-not rules or alternatives 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 annotations only declaring readOnlyHint=false and openWorldHint=false, the description adds real context: it explicitly flags that set/remove/clear are writes (destructive on stored data) and that cookie reads include HttpOnly cookies, a security-relevant capability worth calling out. It still omits whether writes are reversible or whether elevated permissions are needed per area.

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?

Front-loaded with the core purpose, then a dense but well-structured area enumeration and an action/semantics clause. No filler sentences; the only cost is that the second half reads as a compressed glossary rather than scannable structure.

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, no-output-schema tool the description covers the input space well because the schema is fully annotated, but it says nothing about what list vs get returns, how `limit` pagination behaves across areas, or which areas support which actions. An agent can call it, but may pick an invalid area/action combination.

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 baseline is 3, but the description adds meaning the schema does not: it maps `url`/`domain` to cookie scoping, explains the nested path in indexeddb (databases, stores, records) so `key` as "db/store" makes sense, and states the read/write split for `action`. Minor gain over a fully documented schema, not a major one.

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?

Names a specific verb pair (reads and edits) plus a concrete resource domain, then enumerates every `area` value with a short gloss (cookies, local/session, indexeddb, cache, serviceworkers, manifest, quota). The 'like the DevTools Application panel' anchor lets an agent distinguish it immediately from dom_inspect, network_requests, or console_logs.

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 action taxonomy ('list/get read, set/remove/clear write') gives implied guidance on which action to pick, and the area glosses hint at when each area applies. However, there is no explicit when-to-use vs siblings (e.g., versus evaluate or dom_inspect) and no warning that write actions only make sense for some areas (cookies, local, session, cache) while others are read-only (serviceworkers, manifest, quota).

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: closing the session target tab changes session-follow behavior back to the user's active tab, a non-obvious side effect an agent would otherwise miss.

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 filler, with the core action front-loaded and the caveat placed second. Every clause carries information the agent cannot get elsewhere.

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

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

For a single-parameter destructive tool with full annotation coverage, the essentials are present: what it closes, where ids come from, and the session side effect. Minor gap: no statement on behavior for unknown or already-closed tab ids.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds meaning by identifying where tab ids come from (tabs_list) and reinforcing that multiple ids are accepted, matching minItems: 1. It does not explain invalid-id or partial-failure 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?

States a specific verb and resource ('Closes one or more tabs') and scopes it by id, plus names the source of those ids (tabs_list). This differentiates it from tab_open, tab_select, and tabs_list without needing the schema.

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

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

The '(from tabs_list)' parenthetical implies a prerequisite flow, but the description never states when to close versus when to select or navigate away, nor any exclusion. Usage is inferable rather than explicit.

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?

Goes beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing meaningful state effects: the tab is added to the session group and becomes the target tab, and console/network recording begins before the load. Also discloses failure behavior (load errors surfaced as errors) and the blocking/wait semantics. Missing only timeout/permission nuances, which the schema covers.

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 with zero filler; the primary action and its state effects come first, followed by the recording and wait behavior. Every sentence carries distinct 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 browser-navigation tool with a fully described 4-param schema and no output schema, the description covers side effects, recording start, wait behavior, and error reporting. An agent has everything needed to call it correctly and predict its effects.

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 schema already documents url, timeoutMs, waitUntil, and background. The description adds only a clarifying note that 'none' disables waiting, leaving background and timeout semantics entirely to the schema — appropriate baseline for full coverage.

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

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

States a specific verb and resource ('Opens a URL in a new tab') plus the resulting state changes: joins this session's tab group and becomes the session target tab. The 'new tab' framing implicitly sets it apart from navigate/tab_select siblings without needing their 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?

Conveys the operational context (load capture, blocking until load unless waitUntil is 'none') but never names an alternative such as navigate for reusing an existing tab, nor any when-not condition. Usage is implied by describing behavior rather than stated as guidance.

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

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

Annotations declare readOnlyHint=false and idempotentHint=true, but they don't explain what the write actually changes; the description supplies that it mutates persistent session state (the default target) rather than page content, which is valuable context beyond the annotation flags. It also notes the optional window-focus side effect of activation. It omits what happens on an invalid or closed tabId, which keeps it from 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?

A single sentence with zero waste; the primary behavior (setting the session default target) is front-loaded and the optional behavior is correctly subordinated with 'optionally'.

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

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

For a two-parameter, fully documented, non-destructive-to-content operation with no output schema, the description covers the durable effect and the activation side effect adequately. Minor gap: no mention of failure behavior for a stale or invalid tabId, which an agent would want when reusing stored ids.

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

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

Schema description coverage is 100%, so both parameters are already fully documented, and the description's only added mapping is 'brings it to the front' for the activate flag. Baseline 3 applies when the schema carries the parameter burden.

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 ('Makes a tab the default target') and captures the key scope distinction: the selection applies to subsequent tools in this session, not just this call. An agent can distinguish it from tabs_list (enumerate) and tab_open (create) without reading any 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 phrase 'for subsequent tools in this session' implies the right moment to call it (before page-scoped operations on a particular tab), but there is no explicit when-not guidance or named alternative such as using tabs_list to discover ids or tab_open to create a tab first. Usage is inferred rather than directed.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds real value by characterizing the result set (id, title, URL, active/audible, tab group, session target tab), though it says nothing about ordering or size for large tab counts.

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: the capability and its returned fields come first, and the follow-up call guidance comes second. Perfectly 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?

No output schema exists, and the description compensates by enumerating the returned attributes, which is enough to call and consume the tool. Minor gaps remain on result ordering and volume handling for many tabs.

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% and the single parameter is fully documented in-schema, so the baseline is 3. The description's 'in every window' phrasing loosely implies the default filter but adds no syntax or interaction detail beyond 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?

States a specific verb and resource ('Lists every open tab in every window') and even enumerates the fields returned, so an agent knows exactly what it gets. The 'every window' scoping also implicitly distinguishes it from window-scoped listing 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?

Explicitly routes the agent forward: 'Use the ids with tab_select or the tabId parameter of other tools,' naming concrete siblings. It lacks an explicit when-not-to-use clause, which keeps it from a 5.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds substantial behavioral detail beyond that — one trusted key event per character, IME-style commitment for non-US characters, and the >200 character paste-mode threshold unless slowly=true. It also discloses that line breaks are inserted as text rather than triggering Enter, which is a real behavioral gotcha.

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?

Front-loaded with the core action, then layered with mechanics, threshold, and escape hatches — every clause carries information. It is dense to the point of being a single run-on paragraph, which slightly hurts scanability.

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 6-parameter mutation tool with no output schema, yet the description covers mechanics, the long-text fallback, line-break behavior, submit, and clear. It does not cover failure modes such as a missing or stale ref, or what happens when no element is focused, which an agent would need to recover from errors.

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 would be 3, but the description adds meaning the schema lacks: the 200-character threshold at which typing degrades into a paste, and the slowly=true override that forces key-by-key even for long text. It reinforces submit/clear semantics already in the schema rather than duplicating 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?

States a specific verb and resource ('Types text into an element (by ref) or into the focused element') and scopes the target precisely. It also names a sibling (press_key) for the Enter-key case, so an agent can distinguish the two without opening 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?

Gives clear routing guidance for the Enter case ('use submit=true or press_key to press Enter') and tells the agent it can clear first. It does not, however, say when to prefer this over sibling fill_form, or when typing is inappropriate versus evaluate/set-value approaches.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write nature is covered. The description adds the useful constraint that paths must be absolute local machine paths, but says nothing about whether existing attachments are replaced or appended, nor about error behavior when the ref is not a file input.

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

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

A single front-loaded sentence with no filler; the key constraint (absolute local paths) sits in the main clause. It is efficient, though slightly terse for a mutation tool with 3 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 simple three-parameter mutation with full schema coverage and no output schema, the description covers the essentials. It omits attach-vs-replace semantics and failure modes, which an agent would want when the upload doesn't visibly take effect.

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 all three parameters are already documented (ref origin, absolute paths, tabId default). The description reinforces the path format requirement but adds no syntax or constraint detail beyond what the schema states.

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 (attaches) and resource (local files) plus the target (a file input element), and clarifies the path form as absolute paths on this machine. An agent can tell this apart from fill_form or click without inspecting the schema, though it doesn't name the sibling it supersedes for file inputs.

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

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

The phrase 'to a file input element' implies the precondition (the target must be a file input), but there is no explicit when-to-use vs. alternatives such as fill_form or click, and no note on what to do if the element is not a file input.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior: the ordered source waterfall (HTML5 tracks, YouTube captions, player network log) and the explicit 'reports clearly when none' outcome, though it doesn't describe result shape or pagination.

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: what it returns, where it looks, and what happens on failure. Fully front-loaded with zero filler.

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

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

With no output schema, the description still says the return is captions with timestamps and that absence is reported explicitly, which is enough for an agent to interpret results. Only minor gaps remain (result format details, whether ranges are inclusive) and those are cheap to discover.

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% and every parameter (start, end, tabId, video, language) has a description, so the schema carries the semantic load. The description mentions none of them, so it adds no value beyond structured fields — the baseline 3 applies.

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

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

States a specific verb and resource ('Returns the captions/subtitles of a video with timestamps') and enumerates the sources it draws from. An agent can distinguish it from video_transcribe without opening any 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 names the alternative and the condition that selects it: 'Reports clearly when there are none (then use video_transcribe).' That is a direct when-to-use-this-vs-that routing rule, plus the source-order fallback behavior.

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

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

Annotations declare readOnlyHint=false and openWorldHint=false, so the safety profile is already carried by structured data and the mutating nature is consistent with the described actions. The description adds one genuinely non-obvious trait — `play` bypasses the user-gesture requirement — which is real value beyond annotations. It says nothing about failure modes (no video found, invalid ref), whether volume/mute changes persist, or the default targeting behaviour that the schema actually handles.

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 filler: the capability enumeration comes first and the one non-obvious caveat is front-loaded second. Nothing is repeated from the schema and 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?

With six parameters fully documented in-schema and no output schema, the description only needs to frame the operation set and any behavioural gotchas, which it does. The missing piece is a note on what happens when the target video is absent or the ref is stale, but that is a minor gap for a well-specified control tool.

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

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

Schema description coverage is 100% and every parameter is documented in-schema, including the action-to-parameter pairing (rate/time/volume) and the video ref default. The description adds no semantics beyond that, so the baseline of 3 applies.

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

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

The description names a concrete resource (a video) and enumerates every operation the enum supports: play, pause, seek, rate, mute/unmute, volume. That maps one-to-one onto the `action` enum, so an agent knows exactly what the tool does. It does not explicitly separate itself from near-neighbours like video_list or media_inspect, which keeps it 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?

There is no explicit statement of when to choose this over siblings or when not to use it; the only conditional guidance is the note that `play` works on pages requiring a user gesture, which implicitly tells the agent to reach for this tool rather than raw evaluate/click for playback. Usage is otherwise inferable from the action list 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?