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

The description adds substantial behavioral context beyond the readOnlyHint annotation. It discloses where headers come from, how Chrome's issue collection timing works, that the page URL may be fetched once if not recorded, and that cookie values are intentionally not printed. This level of transparency helps the agent anticipate output quirks and avoids surprises, especially since idempotentHint is false.

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 efficient: it opens with the core purpose in the first sentence, then packs each subsequent sentence with unique, non-redundant context. No word is wasted; even the cookie caveat serves both behavioral and usage guidance. It is front-loaded and structured logically, so an agent can quickly grasp the baseline and then dive into nuances.

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 data provenance, timing caveats, expected output format, and explicitly points to a sibling tool for missing details. Since an output schema exists, the description need not explain return values. For a tool with two optional parameters and this complexity, it leaves no critical gaps an agent would need 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?

The schema already provides 100% coverage with detailed descriptions for both parameters, including the full enumeration for 'checks'. The description does not add meaning to any specific parameter; instead, it explains overall behavior and output formats. While it indirectly helps interpret the 'checks' parameter by describing WARN/INFO output, that is not the tool description's job, so it rests at the baseline for fully documented schemas.

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

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

The description clearly states the tool performs a 'passive security review of the selected page' and positions it as a starting point rather than a verdict. This gives a specific verb+resource scope and distinguishes it from a full vulnerability assessment. It also lists what the tool outputs (WARN/INFO) and what it doesn't (cookie values), making its purpose unambiguous.

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

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

The description tells the agent when to use the tool (as a starting point for manual tests) and what it is not (a verdict). It explicitly directs cookie value needs to 'get_cookies', providing a clear alternative. It also explains data-source caveats (recorded vs fetched page) that affect interpretation of results, helping the agent choose correctly in context.

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

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

Annotations provide idempotentHint=true and destructiveHint=false but the description goes far beyond them: it discloses that blocking stylesheets breaks layout-dependent operations, that matching follows Chrome-reported resource types (so extension-less URLs are still caught and types never cross-match), and that the effect is scoped to one tab and resets on new_page. No contradiction with annotations — idempotency and reversibility are consistent with 'call again with no types to unblock.'

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 paragraphs, but every sentence earns its place and the structure is logical: purpose/benefit → side effects → matching semantics → scope/persistence. The most important claim (what it blocks, why) is front-loaded, and the longer sections address genuinely non-obvious behavior that an agent must know before calling.

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

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

For a tool with subtle side effects and scoping, the description covers everything: purpose, benefit, what breaks and what doesn't, matching semantics, persistence across navigations, how to unblock, and the new_page reset. An output schema exists, so return-value explanation isn't required. Nothing an agent needs 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% and both parameter descriptions are excellent: `types` documents the enum values, the recommended scraping combination, and the unblock behavior; `browser` explains the per-agent isolation. Baseline is 3 given full coverage, but the description adds value by clarifying matching semantics (Chrome-reported type, no cross-type matching) that enriches how `types` should be understood. Not a 5 because the core parameter meaning lives in the schema, not the description.

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

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

The description opens with a specific verb+resource ('Block images, fonts, stylesheets or media') and a concrete purpose ('speed up page loads'). No sibling tool performs this action — the closest (bypass_insecure_warning, cf_verify, set_browser_flags) are all distinct — so the tool is clearly differentiated without needing to name a sibling.

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

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

The description gives explicit when-to-use guidance (speed up scraping on media-heavy pages), explicit exclusions ('Blocking stylesheets breaks layout... click_at, element screenshots, and the `visible` check in wait_for_selector become unreliable'), and what is unaffected ('Text extraction is unaffected'). The schema description reinforces this with a recommended combination. Scope (single tab, persists across navigations, new_page starts unblocked) is also spelled out. This is full usage routing with no inference required.

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 provide no behavioral detail beyond flags. The description explains the mechanism (performs the Advanced -> Proceed click) and its limitation (no effect on other pages). It adds value over the annotations but does not mention potential side effects like actually navigating to an insecure page or any security implications, which would strengthen transparency.

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 concise (~100 words) and well-structured: it opens with the action, then provides context, the mechanism, and a caveat. There is no fluff or redundancy; every sentence earns its place.

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

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

For a simple tool with one optional parameter and no required inputs, the description covers when to use it, what it does, and its non-effect. The existence of an output schema (even if not detailed here) means return values are not required to be explained. The description is complete for an agent to invoke it correctly.

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

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

The schema description covers 100% of the parameter, fully explaining the 'browser' parameter including its default and concurrency implications. The tool description itself adds no parameter information, which is acceptable given the schema's thoroughness. Baseline 3 is appropriate.

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

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

The description clearly states the specific action ('Click through Chrome's Your connection is not private interstitial') and identifies the resource (the warning page). It distinguishes itself from sibling navigation tools by focusing exclusively on the SSL/certificate interstitial.

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

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

It explicitly tells when to use it: when a navigation lands on an SSL/certificate warning page instead of the site. It also specifies exclusions ('Has no effect on any other kind of page') and explains the symptom (snapshot shows warning page). This provides clear when-to and when-not-to 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?

The description goes far beyond the sparse annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false). It discloses background execution, browser-wide coverage including workers, the capture.jsonl sidecar, interaction with list_network_requests and get_network_request, memory-in-whole behavior, and exact exclusions. No contradiction with annotations.

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 most important action and scope appear in the first sentence. The remaining paragraphs add necessary behavioral context, exclusions, and integration notes without filler. Every sentence earns its place, and the structure is logical: what, why, scope, exclusions.

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

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

For a complex background-capture tool with six parameters and output schema, the description covers the full behavioral contract: what is captured, what is not, how the files are organized, how it interacts with sibling tools, and a memory warning via the max_body_mb parameter. Nothing essential 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 description coverage is 100%, so the baseline is 3. The description does not add new parameter-level meaning beyond the schema, but it does provide behavioral context that helps an agent understand the lifecycle (start/status/stop) and the inter-tool effects of captured bodies. This keeps it at a solid 3.

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

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

Opens with a specific verb-resource pair: "Save every matching response body to disk the moment it arrives, in the background." It clearly differentiates from get_network_request by explaining that the sibling asks Chrome lazily and often misses bodies, whereas this tool captures them while the response is still paused.

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 contrasts with get_network_request, explains when this tool is necessary (bodies are often gone by request time), and lists concrete exclusions: cache responses, redirects, and event streams inside workers. It also gives actionable advice such as using ignore_cache and keeping patterns off long-running downloads.

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 indicate readOnlyHint=false and idempotentHint=false, implying side effects. The description adds valuable context: it drives nodriver's built-in bypass, locates and clicks the checkbox visually, requires the optional opencv dependency (and reports missing it gracefully), and handles the no-challenge case. It does not contradict annotations and enriches the behavioral picture beyond 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 five sentences with zero fluff. The purpose is front-loaded in the first sentence, usage conditions follow, then dependency and alternative guidance are given concisely. Every sentence earns its place; it is efficient and well-organized.

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 specialized challenge-solving tool, the description covers when to use, the alternative (wait_for), the optional dependency, and the no-challenge fallback. An output schema exists (indicated) to handle return values, so nothing critical is missing. The tool is fully comprehensible and actionable for an agent.

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

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

The schema description coverage is 100% — the single optional 'browser' parameter is fully described in the schema, including its default and the semantics of naming independent Chrome instances. The tool description adds no further parameter-specific information, so it does not exceed the baseline set 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?

The description opens with a specific verb and resource: 'Attempt to solve a Cloudflare Verify you are human challenge.' It precisely names the interstitial types (checkbox widget, 'Checking your browser') and is clearly distinct from all sibling tools, none of which target Cloudflare challenges. This leaves no ambiguity about what the tool does.

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

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

It explicitly states when to use the tool ('Use when a page is stuck on a Cloudflare interstitial') and gives a concrete alternative: 'wait_for([some text from the real page]) is worth trying first' for challenges that self-resolve. It also explains that the tool reports when no challenge is present, covering the fallback condition. This is exemplary usage 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?

Even though annotations already flag destructiveHint=true, the description adds meaningful behavioral detail beyond the structured data: it has no undo, it logs the user out everywhere, localStorage is left untouched, and sites may still recognize the user because of that. This gives the agent a much richer picture of the side effects than the annotations alone.

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 and well-organized: the core action comes first, followed by scope and consequences, then use cases, then a caveat. Every sentence adds value and there is no filler or redundant restating of the tool name.

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

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

For a single-parameter destructive action with an output schema, the description covers everything an agent needs: what is deleted, the scope, irreversibility, restoration path, intended use cases, and a relevant side-effect caveat. The output schema is present, so describing the return value would be redundant.

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?

With schema description coverage at 100%, the single 'browser' parameter is fully documented in the schema, including its default and per-agent semantics. The description does not add parameter-specific information, but it does not need to. Baseline 3 is appropriate because 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 opens with a specific verb and object: 'Delete every cookie in the browser.' It goes further to clarify the exact scope ('Browser-wide, not per site and not per tab'), which clearly distinguishes this from per-site cookie tools like get_cookies and set_cookie. The phrase 'logs you out of everything' reinforces the practical effect without 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 description gives concrete use cases: 'testing a first-time-visitor flow or resetting a consent banner decision.' It also points to an alternative restoration path with load_session. It stops short of saying when not to use this tool, but the guidance is clear enough for an agent to decide.

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 discloses far more than the annotations: real CDP input events, isTrusted=true, hit-testing behavior, fallback to synthetic clicks, touch-emulation crash risk, 10-second bounds, and response path reporting. This is exactly the behavioral context an agent needs.

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 long but every sentence earns its place: purpose, sibling differentiation, stealth behavior, fallback conditions, timeout safety, and error recovery. It is front-loaded and structured in clear paragraphs.

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

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

Given the tool's complexity, the rich schema, and the presence of an output schema, this description covers everything needed to invoke it correctly: when to use it, how it behaves, what can go wrong, and how to recover. Nothing essential 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 description coverage is 100%, so the schema already documents every parameter thoroughly. The description adds some context around if_covered and uid invalidation, but it does not need to compensate for missing schema documentation.

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: 'Click an element addressed by its snapshot uid.' It also explicitly distinguishes itself from click_at, so an agent can tell which tool to use without opening the sibling schema.

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

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

It explicitly says to prefer this tool over click_at and explains why, gives recovery steps for an 'unknown uid', and describes when the scripted fallback is forced. This is concrete, actionable guidance for choosing and using the tool.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context beyond those: it warns that coordinate clicks are not robust against layout shifts, clarifies that coordinates are in CSS pixels and ignore device pixel ratio, requires the point to be inside the viewport, and notes 'Same input path as `click`: real CDP events, the same reported scripted fallback, the same 10s bound per step.' This fully discloses the behavioral profile without contradicting any 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 five sentences, each densely informative. It front-loads the core purpose and the key differentiator from `click`, then covers usage scope, coordinate constraints, and behavioral parity. There is no filler or repetition; every sentence earns its place.

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

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

The tool has an output schema, so return value documentation is not required. The description covers the essential context for correct invocation: the target use cases, the distinction from `click`, the viewport requirement, the coordinate system, the robustness caveat, and the behavioral parity with `click`. For a 5-parameter tool with a rich sibling set, nothing an agent needs to call 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% (all 5 parameters have descriptions), so the baseline is 3. The description adds meaningful semantics for x and y by stating 'Coordinates are in CSS pixels and ignore the device pixel ratio, so they match what emulate/resize_page report' and by explaining the viewport requirement. It does not elaborate on browser, dbl_click, or include_snapshot beyond the schema, but those are already well-documented. The added coordinate semantics justify a slight bump to 4.

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: 'Click a raw viewport coordinate instead of an element.' It immediately distinguishes from the sibling 'click' by contrasting coordinate-based vs. element-based targeting. The subsequent sentence, 'Use `click` with a uid whenever the target shows up in a snapshot — it is robust against layout shifts, this is not,' explicitly names the sibling and the deciding condition, leaving no ambiguity about what this tool does.

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

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

The description gives explicit when-to-use and when-not-to-use guidance. It states coordinates are for 'surfaces with no addressable element: canvases, maps, video players, image hotspots' and that `click` should be used when a snapshot shows the target. It also provides a prerequisite: 'scroll_page or scroll_to_selector first if it does not [lie inside viewport].' This is model guidance for choosing the right tool.

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

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

Annotations already declare destructiveHint=true, but the description goes far beyond: it details that cookies/logins/localStorage are discarded on temp profiles but preserved on persistent ones, that the browser relaunches automatically, that the name/profile/flags survive and count against the 12-browser limit. This adds critical behavioral context that annotations alone don't provide. No contradiction with annotations.

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 longer than a typical one, but every sentence earns its place: main purpose, contrast with close_page, behavior on relaunch, side effects on temp vs persistent profiles, persistence of name, and the alternative shutdown_browser. It is front-loaded with the core action and uses structured paragraphs. Slightly verbose but not wasteful — well organized.

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

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

Given the tool's complexity, the description is remarkably complete. It covers all relevant behaviors: what happens to cookies/data, what persists across relaunch, the browser limit, and the distinction from shutdown_browser. An output schema exists, so return values need not be explained. Nothing an agent needs to correctly invoke or decide when to use this tool 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?

The input schema for the single 'browser' parameter is fully described (100% coverage) and includes a clear explanation of what each name represents and how to use the default. The tool description itself does not add any additional meaning about the parameter — it focuses on the tool's overall behavior. Since the schema already covers the parameter semantics thoroughly, a baseline of 3 is appropriate.

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

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

The description clearly states the tool 'Quit Chrome entirely, closing every tab' — a specific verb and resource. It explicitly contrasts with close_page (which keeps one tab alive) and shutdown_browser (which releases the name), making sibling differentiation unambiguous. An agent can immediately tell what this tool does and how it differs from close_page and shutdown_browser.

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

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

It gives explicit when-to-use guidance: it mentions it's how you apply pending launch flags without switching profiles, and when to use shutdown_browser instead ('When an agent is finished for good'). It also advises calling save_session first on temp profiles to preserve data. This is strong, actionable routing to the correct tool in different scenarios.

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, readOnlyHint=false, and idempotentHint=false. The description adds valuable context beyond these: the last-tab restriction, selection clearing side effect, and the fact that the tool returns remaining pages with shifted indices. No contradiction with annotations.

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 efficiently written in three short paragraphs. The core action is front-loaded, followed by a key exception and then important side effects and return info. Every sentence adds value without redundancy.

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

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

For a simple two-parameter tool with a complete input schema and an output schema, the description fully covers usage, constraints, side effects, and return behavior. Nothing essential is missing for an agent 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?

The input schema provides full descriptions for both parameters (browser and page_id), covering their defaults and meanings. The description does not add new parameter-specific semantics; it only reinforces the default behavior and return value, which are already in the schema. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description states the specific verb 'close' with resource 'a single browser tab', making the action clear. It also distinguishes itself from close_browser by explicitly noting the last-tab limitation and the alternative for shutting down entirely.

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

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

The description gives explicit when-to-use guidance: it states that the last remaining tab cannot be closed and instructs to use close_browser instead. It also explains the behavior after closing (selection cleared, fallback) and advises re-reading returned pages due to index shifts, which informs the agent on how to correctly use the tool's output.

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 convey idempotentHint=true and destructiveHint=false, and the description reinforces and extends this by saying creation is harmless until activation, existing profiles are left untouched rather than overwritten, and profiles live under ~/.nodriver-mcp/profiles/<name>. It also discloses the single-instance constraint, which is valuable behavioral context beyond the annotations.

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 and front-loaded with the core purpose, followed by persistence semantics, safety, storage location, and concurrency warning. Each paragraph earns its place, though there is slight redundancy with the browser parameter's 'parallel agents each need their own name' 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 tool with three parameters, an output schema, and strong annotations, the description covers the important behavioral ground: what persistence means, when activation happens, that creation is non-destructive, where files live, and the concurrency limitation. It is complete enough for an agent to select and invoke the tool safely.

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 name, browser, and activate thoroughly. The description adds a bit of extra context around profile storage location and concurrency, but it does not substantially change or deepen parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Create a named persistent Chrome profile' and immediately clarifies it is a reusable user-data dir. It also differentiates itself from siblings by calling out save_session/load_session as a weaker alternative and mentioning use_profile as a later activation path.

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

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

The description gives clear usage context: use a persistent profile when you want cookies, logins, and extensions to survive between runs, and it explicitly names save_session/load_session as the alternative. It also gives practical guidance about concurrent browser instances needing different names. It stops short of an explicit 'use this instead of X when...' matrix, but the comparison is strong.

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 destructiveHint=true annotation, the description discloses irreversibility, the exact data removed (cookies, logins, history, extensions), that deletion is from disk, and that there is no undo. It also states a behavioral restriction (active profile cannot be deleted). These details meaningfully exceed the annotation's binary signal and match it without contradiction.

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 — action first, then irreversibility/effects, then the key usage constraint. Every sentence carries information; there is no filler or redundancy beyond the deliberate emphasis on 'no undo'.

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 what is deleted, permanence, the active-profile constraint, and how to work around it. An output schema exists to handle return values, annotations carry the destructive hint, and the schema documents the parameters. Nothing an agent needs 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 description coverage is 100%, so the parameters name and browser are already fully documented in the schema. The description adds no parameter-specific semantics beyond the general persistent-profile context; it neither enriches nor contradicts the schema.

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

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

The description opens with 'Permanently delete a persistent Chrome profile directory' — a specific verb, resource, and scope. It clearly distinguishes this from sibling tools like list_profiles, create_profile, use_profile, and use_temp_profile, leaving no ambiguity about what the tool does.

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

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

The description gives an explicit constraint and alternative: 'The active profile cannot be deleted — switch away with use_temp_profile first.' This addresses when not to use the tool and names the relevant sibling. It does not explicitly state general when-to-use scenarios, but the purpose makes the primary use case obvious.

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

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

Beyond the annotations, the description discloses meaningful behavioral details: turning the CDP Runtime domain back off, restoring a quieter and harder-to-detect default, and preserving already-collected messages while stopping new ones. It also aligns with the idempotentHint annotation since calling it again is safe. No contradiction with annotations.

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 well structured: one concise action sentence, one contextual sentence about why this matters, and one sentence describing the side effect. Every sentence earns its place and there is no filler.

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

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

For a tool with one optional parameter, an output schema, and helpful annotations, the description covers everything an agent needs: what it does, when to call it, and what side effects to expect. There is no meaningful gap in context.

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

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

Schema description coverage is 100% for the single browser parameter, and the schema already explains the browser naming semantics and default behavior. The description adds no additional parameter-specific guidance, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Stop capturing console output on the current page.' It clearly identifies the tool as the inverse of enable_console_collection and adds technical grounding by mentioning the CDP Runtime domain. This makes the purpose unambiguous and distinguishable from sibling tools.

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

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

The description gives an explicit condition for use: 'worth doing once you are finished debugging and the page still has anti-bot checks ahead of it.' It implies the opposite of enable_console_collection but does not explicitly name that sibling or state when not to use it, so it falls just short of a full 5.

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

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

Annotations already declare readOnlyHint=false, but the description goes beyond them by explaining the actual behavioral steps (scrolling into view, hit-testing, stepping pointer movement). It also discloses the significant limitation that synthetic mouse events do not trigger native HTML5 drag-and-drop in Chrome. This adds valuable context beyond the structured annotations without contradiction.

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 lean and well-structured. The core action is stated in the first line, followed by a concise prerequisite sentence and a crucial caveat. Every sentence earns its place—no fluff, and the most important information (action + constraint) is front-loaded.

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

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

The description covers all essential context for correct usage: the prerequisite of snapshot UIDs, the hit-testing and scrolling behavior, the stepping pointer movement, and the critical HTML5 drag-and-drop limitation. An output schema exists, so return values need no explanation. There is nothing an agent needs to know to invoke this tool correctly that 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?

The input schema provides 100% coverage for all four parameters, each with a description. The tool description does not add additional syntactic or semantic detail beyond what the schema already encodes (e.g., the same-snapshot constraint is already in the schema descriptions for from_uid and to_uid). Baseline of 3 is appropriate when the schema carries the parameter documentation 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?

The description begins with a specific verb-resource pair ('Drag one element onto another') and immediately conveys the press-move-release mechanism. It distinguishes itself from sibling tools like click, hover, and scroll by detailing the drag-and-drop nature and the pointer movement behavior, making it clear what makes this tool unique.

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

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

The description gives a concrete prerequisite (both uids from the same take_snapshot) and explains the intended use case for mouse-driven sortables and sliders. It also warns against a common failure mode (native HTML5 drag-and-drop) and explains why it won't work. It does not explicitly name alternative tools, but the context is strong enough to guide selection.

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

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

Beyond the annotations, the description discloses important behavioral traits: settings persist across navigations, already-applied settings are carried over rather than dropped, and enabling touch changes click behavior to a scripted path with isTrusted=false. It also warns about client-hint contradictions that can reveal automation. This is rich, non-obvious context that annotations alone do not provide.

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 well-structured and front-loaded with the core purpose, followed by scope, parameter behavior, sibling distinction, and a critical side-effect warning. Every paragraph earns its place, and nothing is redundant with the schema.

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

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

For a tool with 7 optional parameters, full schema coverage, an output schema, and clear annotations, the description is complete. It covers persistence, cross-parameter interactions, how to clear overrides, when to prefer emulate_device, and a dangerous interaction with click behavior. An agent has what it needs to select and invoke the tool correctly.

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

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

The input schema already covers all 7 parameters with 100% coverage, so the baseline is 3. The description adds meaningful cross-parameter semantics: every parameter is independent, pass only what you want to change, settings in force are carried over, and empty strings or notouch/nomobile clear/disable overrides. This goes beyond the individual schema 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 opens with a specific verb and resource: 'Emulate network, CPU, geolocation, user agent, color scheme or viewport.' It clearly distinguishes the tool from siblings by naming emulate_device and reset_emulation as the related alternatives, so an agent knows exactly what this tool does and what it does not do.

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

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

The description explicitly states when to use this tool versus emulate_device: for real phone/tablet emulation, use emulate_device because it sets a coherent set of overrides. It also explains persistence until reset_emulation and emphasizes the independence of parameters, giving an agent clear conditions for invocation.

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 idempotentHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: it sets multiple signals together to avoid contradictions, survives navigation, and the ipad_air preset deliberately reports desktop-class Safari with touch and no client hints. It also names the reset mechanism, giving the agent a complete behavioral model.

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 richly informative but every sentence earns its place: purpose, when-to-use, preset specifics, lifecycle behavior, and undo path. It is front-loaded with the core purpose and does not waste words on restating the schema.

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

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

With 6 parameters, full schema coverage, an output schema present, and annotations covering safety/idempotence, the description completes the picture: it covers alternatives, first-request caveat, navigation persistence, preset semantics, and undo. Nothing an agent needs to invoke this 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining why presets are preferable (signals cannot contradict each other, and mismatch is a classic automation tell) and by describing the real-world behavior of the ipad_air preset. This helps the agent choose parameters more intelligently than the schema alone would.

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: 'Emulate a phone or tablet with one internally consistent set of signals.' It clearly distinguishes itself from the sibling `emulate` tool by positioning this as the preferred preset-based approach for mobile work, and from `reset_emulation` as the undo path.

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

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

The description explicitly states when to use this tool ('Preferred over assembling `emulate` parameters by hand for mobile work'), when not to use it ('To have mobile signals present on a page's very first request, pass `device` to new_page or navigate_page instead'), and how to undo it ('Undo with reset_emulation'). This is exemplary routing guidance.

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

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

Beyond the annotations, the description discloses the CDP Runtime domain and the anti-bot detection risk, explaining the opt-in design. It also clarifies the per-page scope, which is behavioral context not covered by annotations. It does not repeat idempotency (already in annotations) and avoids contradicting 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?

Four sentences, each adding distinct value: purpose, dependency, rationale, and scope. The most important info (what it does) is front-loaded. Slightly longer than strictly necessary, but every sentence earns its place.

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

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

Together with the output schema (which removes the need to describe return values) and annotations (idempotency), the description covers prerequisites, when to use, and per-page behavior. It could mention statefulness (that it remains on until disabled) but that is implied by 'when you are done debugging.' Overall complete for this 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?

The schema description covers 100% of the single 'browser' parameter, including its meaning and default behavior. The tool description adds no extra parameter guidance, which is acceptable given full schema coverage. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Start capturing') and resource ('console output on the current page'), making the core purpose unmistakable. It also distinguishes itself from related tools by noting that list_console_messages and get_console_message depend on this call, and by contrasting with network capture which is always on.

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 instructs when to use this tool: before any console-reading tool, and when stealth is not a concern. Also provides when-not-to-use: leave it off while stealth matters, and use disable_console_collection when done. Names the alternatives (list_console_messages, get_console_message, disable_console_collection) and contrasts with network capture which needs no equivalent call.

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

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

It reveals behavior well beyond the annotations: main-world vs isolated-world execution, uid-to-live-element binding, JSON-serialisability constraints, thrown-error handling, and the rationale for script_path. The readOnlyHint=false and idempotentHint=false annotations are consistent with running arbitrary page JavaScript, and the description adds the operational detail an agent needs.

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

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

The description is dense but every sentence earns its place: core definition, usage rationale, argument modes, return/error behavior, and file-based alternatives. It is front-loaded with the one-sentence definition and uses short paragraphs that are easy to scan.

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 high-complexity, arbitrary-JavaScript tool with six parameters and rich schema descriptions, this description covers the execution environment, argument passing, result serialization, failure semantics, and file-based workflow. The existing annotations already carry the read-only/destructive hints, so nothing an agent needs to invoke the tool 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%, and the schema already documents each parameter well. The description still adds useful meaning: the main-world page-level mode without args, the element-reference mode with args, and the practical constraint that DOM nodes, functions, and circular structures must be mapped to plain values. Some of the script_path/file_path guidance partly duplicates the schema, so the added value is real but not maximal.

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

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

The opening sentence states the exact action ('Run JavaScript inside the page') and result ('get the result back as JSON') with a specific verb and resource. The 'escape hatch' framing with concrete examples distinguishes it from the many action-oriented sibling tools such as click, fill, and take_snapshot.

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

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

The description gives explicit conditions for use: when the other tools do not cover a need, and for computed styles, calling a page's own JS API, or single-round-trip data extraction. It also routes between inline functions, script_path, and file_path. It does not name a specific sibling to prefer in a particular case, so the guidance is clear but not fully exclusionary.

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 carry almost no signal (all flags false), so the description bears full behavioral disclosure — and it delivers: it reveals the write-tenor (readOnlyHint=false is consistent), the full payload contents including live session cookies/tokens, the body-source fallback chain (capture_bodies files first, then Chrome buffer), and adds a security warning to treat the file like a password. This significantly exceeds what the sparse annotations provide.

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 longer than average (three paragraphs) but every block earns its place: purpose/format compatibility, then content and body-sourcing behavior, then the security caveat. It is front-loaded with the core purpose and leads into increasingly operational detail, with no filler or restatement 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-parameter tool with an output schema, the description covers all the behavioral essentials an agent needs: what the file contains, where response bodies come from and when they are incomplete, how to get complete bodies via capture_bodies, and the session-token sensitivity. With an output schema present, return-value documentation is not required, and the capture_bodies interplay is explicitly handled.

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% with already-detailed parameter descriptions (browser explains parallel-agent semantics, include_bodies explains the fallback). The description reinforces the capture_bodies relationship that maps to include_bodies, adding some cognate context, but it does not systematically extend each parameter's meaning beyond the schema. The schema does the heavy lifting, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource — "Write the network log to a HAR 1.2 file" — and immediately distinguishes this from read-oriented siblings like list_network_requests and get_network_request by specifying file export. The format detail and the tool-importability list (Burp, ZAP, Chrome DevTools) make the function unambiguous even before reading 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 gives clear when-to-use context: "start a capture first for a HAR that has every body," explicitly routing the agent to capture_bodies for the complete case and warning that Chrome's buffer otherwise only holds recent requests on the current tab. This effectively names the prerequisite/collaborating tool. It stops short of explicit when-not-to-use statements or direct naming of alternative tools, 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?

Beyond the annotations, the description reveals the type-over mechanism, input-event firing for controlled components, the deliberate avoidance of blanking the field first, select change dispatch, and a post-condition read-back that errors on failure. It also explains external complications like overlays or read-only fields. No contradiction with the annotations.

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 detailed but every sentence earns its place: mechanics, rationale, failure behavior, and routing to alternatives are all distinct and purposeful. It is front-loaded with the core action and structured logically.

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

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

Given the output schema and fully described parameters, the description covers use cases, failure modes, parameter caveats, and sibling routing. An agent has everything needed to invoke fill correctly and interpret unexpected outcomes.

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

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

The schema already covers all parameters at 100%, so the baseline is 3. The description adds useful behavioral meaning around how the value is entered and verified, and reinforces the select value-vs-label nuance, elevating it slightly beyond the schema alone.

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

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

The description opens with a specific verb and resource: 'Set the value of an input, textarea, select or contenteditable element.' It clearly differentiates itself from siblings by stating it replaces the field contents, and explicitly contrasts itself with type_text and fill_form.

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

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

The description explicitly says when to use type_text instead (append to a focused field) and when to use fill_form (several fields at once). It also provides context about uid freshness and failure modes, giving the agent actionable guidance on when this tool is appropriate.

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 reveals important behavioral details not captured by annotations: fields are processed in order, later fields may depend on earlier ones, a failing field does not abort the remaining fill, and the response reports per-uid success/error. This goes well beyond the annotation hints and gives the agent accurate expectations about partial failures and ordering side effects.

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

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

The description is tightly structured: a one-sentence summary, a comparison with the sibling `fill`, and a note about ordering and failure handling. Every sentence contributes distinctive behavioral or usage information, and there is no redundant repetition of schema or annotation content.

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?

Combined with the fully described input schema and annotations, the description covers what the tool does, how it differs from `fill`, ordering semantics, failure behavior, and partial-fill visibility. An output schema exists, so return values do not need to be re-explained, and nothing critical 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 description coverage is 100%, so the schema already documents all parameters, which earns a baseline of 3. The description adds meaning beyond the schema by explaining that `elements` are processed in the given order and that the result reports per-uid success or error, deepening the agent's understanding of the key parameter.

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

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

The description opens with the specific verb-resource pair 'Fill several form fields in a single call', which clearly states the action and scope. It explicitly contrasts itself with the sibling `fill` by noting it behaves like `fill` per field but costs one round trip, distinguishing the two tools 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?

The description gives clear context by explaining that this tool batches multiple fields into one round trip and references `fill` as the per-field equivalent. It does not explicitly state 'use this for multiple fields and fill for a single field', but the efficiency motivation and the sibling comparison strongly imply the appropriate usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail beyond that: it reports box position/size and viewport status, explains the default filtering of properties (only those differing from browser default) and why (several hundred entries), which is critical for correct use. No contradiction with annotations.

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

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

The description is a tight set of four short paragraphs, each serving a distinct purpose: core function, explanation of value, box reporting, and default filtering rationale. It is front-loaded with the primary verb and resource. No wasted words.

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

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

The description covers purpose, usage context, and key behavioral traits. With an output schema present, the return format is handled. It does not mention error conditions or edge cases (e.g., what happens if the selector matches nothing), but those are typically outside description scope. Overall it is complete for an agent to call this tool effectively.

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 is already documented. The description adds context about the default behavior of the 'properties' parameter and explains why omitting it is usually best. This adds value but does not significantly change the meaning of the parameters; the schema already carries the load.

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

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

The description clearly states the tool reads an element's computed styles as the browser resolved them, and distinguishes it from other tools by emphasizing it answers questions about the cascade (visibility, CSS variables, fonts) and reports box geometry. It is distinct from siblings like evaluate_script or take_snapshot.

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

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

The description implies when to use it: to understand why an element is invisible or not clickable, or to resolve computed values that stylesheets alone cannot. It does not explicitly name alternative tools, but the context is clear enough for an agent to decide. A minor gap is the lack of explicit 'do not use when...' 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?

Annotations already establish read-only and non-destructive behavior. The description adds valuable context beyond those: the CDP Runtime domain is disabled by default, enabling it is detectable by sites, and this tool requires prior collection to be enabled. That meaningfully informs the agent of operational constraints.

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

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

Three sentences, each earning its place: the core action, the use-case distinction, and the prerequisite. It is front-loaded and free of 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?

An output schema exists, so return values are covered. The description handles the prerequisite, relationship to sibling tools, and the id source. Nothing needed to call this tool 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 adds extra meaning by explaining how to obtain msgid ('as shown in square brackets by list_console_messages') and by tying the purpose directly to the truncated list output, which helps the agent connect the two tools.

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, resource, and scope: 'Read one console message in full, by id.' It immediately distinguishes itself from the sibling list_console_messages by noting that tool truncates entries, so an agent knows exactly what this tool is for.

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 identifies when to use this tool instead of list_console_messages (to get complete stack traces or error payloads) and states a mandatory prerequisite: enable_console_collection must be called first. This is strong routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuine value beyond that: the whole-jar vs. url-filtered behavior, and the sensitive nature of the output ('Values are returned in full... contains live session tokens'). This is meaningful behavioral context an agent needs before calling.

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

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

Three short paragraphs with no filler: purpose, then scope+sensitivity, then routing to alternatives. The core action is front-loaded in the first sentence, and every sentence earns its place by adding either behavioral or routing 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 two-optional-parameter, read-only tool with a present output schema and full schema coverage, the description covers everything an agent needs: what it returns, its scope, sensitivity, and when to use alternatives instead. The output schema handles return-value details, so nothing 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% and both parameter descriptions are already thorough (url's domain/path/secure matching semantics, browser's independent-Chrome behavior). The description reinforces the url scope ('unless you pass url') but adds no new parameter-level meaning 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?

The description opens with a specific verb and resource — 'List browser cookies with their domain, path and secure flag' — and immediately clarifies scope ('Reads the whole browser cookie jar, not just the current page'). This distinguishes it from sibling write/delete tools like set_cookie and clear_cookies, and from persistence tools like save_session.

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

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

The final sentence gives explicit when-not guidance: 'To carry these across a browser restart use save_session, or switch to a persistent profile with use_profile.' This names the alternatives and the condition that selects them. The url parameter is also framed as a scoping choice (whole jar vs. filtered).

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 destructiveHint=false, and the description adds valuable behavioral details: 200-character truncation, per-origin scoping, about:blank behavior, and sessionStorage exclusion. This goes well beyond the structured annotations.

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 and front-loaded with the core purpose. Each sentence adds distinct useful information: truncation, the alternative for full values, origin scoping, and the about:blank edge case. No filler is present.

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

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

Given the output schema exists, annotations cover the safety profile, and the single parameter is fully documented, the description covers the key edge cases and alternatives needed for correct invocation. Nothing essential 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?

The only parameter, browser, is fully documented in the input schema with 100% coverage, so the description does not need to add parameter details. It neither repeats nor contradicts the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Read all localStorage entries for the current page's origin.' It clearly defines scope and differentiates itself from related tools by noting what is not included (sessionStorage) and by pointing to evaluate_script for full-value retrieval.

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

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

It explicitly tells the agent when to use an alternative: use evaluate_script for a single full entry because values are truncated. It also warns that about:blank returns nothing and instructs to navigate to the site first, giving clear usage context and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds critical behavioral details beyond annotations: inline bodies are truncated at 5000 characters, and response bodies are only available while Chrome holds them in its buffer. These are non-obvious constraints an agent must know to call the tool correctly.

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 tightly written paragraphs: first states the purpose in one sentence, second gives the use case and comparison to DOM scraping, third covers the two key constraints. Every sentence adds information; the most critical detail (what it inspects) is front-loaded. 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?

The tool has an output schema (indicated by has output schema: true), so return values are covered elsewhere. The description covers the only other operational gaps: truncation, buffer lifetime, and binary handling via file paths. For a read-only inspection tool with optional parameters, this is 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 all four parameters are already documented. The description adds value by explaining when to use file paths ('for anything larger' than 5000 characters) and ties the truncation constraint to request_file_path/response_file_path. This supplements the schema without redundancy.

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 ('Inspect') and resource ('one network request') and enumerates exactly what is returned (URL, method, resource type, both bodies). It explicitly contrasts with list_network_requests ('find the page's own API call with list_network_requests, then read the JSON it already received here'), which distinguishes it from its sibling without 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 description provides a concrete workflow: use list_network_requests to locate a request, then use this tool to read its JSON rather than scraping the DOM. It also gives situational guidance for large bodies (use file paths) and warns about response buffer lifetime. This is explicit when-to-use context that routes the agent correctly.

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 readOnlyHint/destructiveHint annotations, the description discloses the live-DOM semantics ('Returns the DOM as it stands right now') and the resulting async-rendering caveat, plus performance traits (no accessibility tree built, no markup overhead). These are genuine behavioral facts an agent needs that the annotations do not convey, and there is no contradiction with the readOnly hint.

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 sentences, each earning its place: purpose, cost/performance positioning, behavioral caveat, and sibling routing. The core purpose is front-loaded in the first sentence, and there is zero filler or repetition of schema content.

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

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

For a 5-parameter tool with 100% schema coverage, an output schema, and safety annotations, the description covers everything an agent needs for correct selection and invocation: what it returns, when to prefer alternatives, and the key timing caveat. The remaining parameter details are fully handled by the input schema.

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

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

Schema description coverage is 100%, so the baseline 3 applies; the schema already richly documents format (innerText vs outerHTML), frame isolation, file_path for large pages, and max_chars truncation. The description adds marginal semantic color ('text form carries no markup overhead') but does not meaningfully compensate beyond the schema's existing 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?

The first sentence states a specific verb and resource ('Get the page's visible text, or its full HTML') and the description repeatedly differentiates from siblings: take_snapshot (provides uids, builds accessibility tree) and query_selector (specific elements). An agent can distinguish this tool from its nearest alternatives without opening 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?

The description gives explicit when/when-not guidance with named alternatives: use this as 'the cheapest way to read a page when you only need content,' 'Use take_snapshot when you intend to interact with elements,' and 'query_selector when you want specific elements.' It also tells the agent to call wait_for or wait_for_selector first on asynchronously rendering pages. Nothing 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds crucial runtime behavior: dialogs block the page and all subsequent tool calls, calling with no open dialog returns an error, and beforeunload dialogs are auto-handled elsewhere. This meaningfully helps an agent predict consequences before invoking the 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?

The description is compact and front-loaded: purpose in the first sentence, actionable urgency in the second, and the key exclusion in the third. Every sentence contributes necessary operational information without redundancy.

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

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

With a complete parameter schema, clear annotations, and an output schema present, the description provides all essential behavioral context an agent needs. It covers when to call, what happens if unused, error behavior, and the beforeunload exception, leaving no significant gap.

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

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

Schema description coverage is 100%, and each parameter already has a detailed description, so the baseline is 3. The tool description itself does not add further parameter-level detail beyond what the schema already provides.

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

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

The description uses a specific verb ('Answer') with a specific resource ('an open JavaScript dialog — alert, confirm or prompt'), immediately clarifying what the tool acts on. It also distinguishes itself from beforeunload handling by pointing to navigate_page, which separates it from related navigation tools.

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

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

The description explicitly says to call this tool as soon as a dialog appears, warns that it blocks subsequent calls, and states that an error is returned if no dialog is open. It also draws a clear boundary: beforeunload dialogs are handled by navigate_page's parameter, so this tool is only for page-initiated dialogs.

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 the annotations, disclosing that the element is scrolled into view and hit-tested, that a sticky header can redirect the hover, and that obstruction reports what is covering the element instead of hovering the wrong target. This is substantial behavioral context beyond readOnlyHint/destructiveHint.

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 front-loaded with a one-sentence definition, followed by tightly focused supporting paragraphs on workflow and behavior. Every sentence earns its place; there is no repetition of schema content or filler.

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

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

For a tool with three well-documented parameters, an output schema, and annotations, the description is complete. It covers the core use case, the snapshot round-trip optimization, hit-testing mechanics, and failure behavior, so an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explicitly tying include_snapshot=true to the hover workflow—'get the revealed content back in the same call'—which helps the agent decide when to set 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 opens with a specific verb and resource: 'Move the mouse over an element without clicking it.' It clearly distinguishes hover from click and gives the core use case, so an agent can tell what the tool does without 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?

It gives clear context for when to use the tool: 'open hover-triggered menus, tooltips and dropdowns before reading what they reveal.' It does not explicitly name alternatives or when-not-to-use conditions, but the guidance is strong enough to route the agent correctly.

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?

Even with readOnlyHint=true and destructiveHint=false in annotations, the description adds substantial behavioral context: credential-looking values are flagged, JWTs are decoded without signature verification, reading happens via DevTools rather than page JavaScript, and IndexedDB/Cache are only listed with sizes rather than dumped. This goes well beyond what annotations alone convey.

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

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

The description is dense but every sentence earns its place: scope, security warning, JWT behavior, read mechanism, and limitations. It is front-loaded with the core purpose and avoids unnecessary filler.

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

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

For a tool with two optional parameters, full schema coverage, an output schema, and safety annotations, the description covers all essential behavioral aspects: what is inspected, how values are handled, what is not dumped, and how to get full records. No critical gap remains for an agent deciding whether and how 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by tying reveal_values to the credential-flagging behavior and by clarifying that redaction shows first characters and length by default. The browser parameter is already well documented in the schema.

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

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

The description opens with a specific verb and resource ('Everything the selected page's origin keeps in the browser') and enumerates exactly which storage types are covered: localStorage, sessionStorage, IndexedDB, Cache Storage, service workers, and quota usage. This clearly distinguishes it from narrower siblings like get_local_storage.

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

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

It gives explicit context that reading is done through DevTools, not page JavaScript, with one named exception. It also provides a clear alternative for a specific case: 'use evaluate_script to read records' for IndexedDB and Cache Storage contents. It does not explicitly contrast with get_local_storage, but the scope statement makes the distinction clear.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavior beyond that: 'Reports without starting anything,' the meaning of chrome_running=false, and the relationship with close_browser and implicit browser creation. This fully informs an agent about side-effect-free behavior and state semantics.

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 slightly longer than minimal but every sentence adds meaning: return fields, no side effects, implicit creation, default browser existence, and chrome_running=false semantics. The core purpose is front-loaded in the first sentence.

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

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

With no parameters and no output schema, the description carries the full burden and succeeds: it lists the returned fields, explains the default browser, clarifies missing names, and defines the chrome_running flag. An agent has everything needed to invoke and interpret the tool correctly.

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

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

There are zero parameters, so the description carries no parameter burden. The baseline of 4 applies, and the description does not waste space inventing unnecessary parameter guidance.

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 first sentence states a precise verb and resource: 'List every browser this server currently holds' followed by the exact fields returned. It clearly differentiates from sibling list tools like list_pages and list_sessions by focusing on browser-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?

The description explains when results are meaningful: only browsers already created are shown, a missing name is not an error, and 'default' always exists. It gives strong context for when to trust the output, though it does not explicitly name alternative tools or state 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?

Annotations already mark the operation as read-only and non-destructive, but the description adds meaningful behavioral context: console capture is opt-in due to CDP Runtime debugger detection, messages are id-prefixed and truncated to 200 characters, and only the most recent 1000 messages are retained.

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

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

The description is three sentences with no filler. Purpose is front-loaded, followed by the critical prerequisite/why, then the key line-format and retention constraints. Every sentence earns its place.

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

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

With detailed parameter schemas and an output schema present, the description covers the remaining essential context: prerequisite setup, degraded behavior without it, truncation, and retention limits. Nothing critical is missing for an agent 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 description coverage is 100%, and the schema already documents all five parameters precisely, including the 'warning' vs 'warn' distinction, browser naming, pagination, and preserved messages. The description adds return-format context but does not need to repeat parameter 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?

The description opens with a specific verb and resource: 'List console output collected for the selected page.' It clearly distinguishes itself from the sibling get_console_message by explaining that lines are truncated and ids can be used to fetch the full text.

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

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

It explicitly states the prerequisite 'Requires enable_console_collection first' and warns that without it the tool returns a reminder instead of messages. It also directs the agent to get_console_message when full text is needed, providing a clear path between related 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?

Annotations already declare readOnlyHint=true, and the description adds significant behavioral context: Chrome's accessibility tree stops at frame boundaries, querySelector never crosses them, and index 0 is always the main frame. It also explains how results should be consumed by other tools. This goes well beyond the annotations and meaningfully clarifies tool 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?

The description is front-loaded with the core action and purpose, then provides a brief but necessary explanation of the frame boundary problem, and closes with concrete usage instructions. Every sentence contributes value; there is no filler or repetition of the title or schema.

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

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

For a read-only listing tool with a single optional parameter and an output schema, the description is complete: it explains why the tool exists, when to use it, what the output means (index 0 main frame), and how to use the result with related tools. Nothing necessary 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 description coverage is 100%, and the only parameter, browser, is fully documented in the input schema with its own description. The tool description does not add parameter-level detail, which is fine because the schema already carries the full burden. 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 starts with a specific verb and resource: 'List the page's frames'. It then explains the purpose: making frame content reachable, which distinguishes this tool from take_snapshot and query_selector, which operate only on the main frame. The clear framing of iframe content as otherwise invisible gives the tool a precise identity.

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

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

The description explicitly explains when to use list_frames: whenever content lives inside an iframe and is invisible to take_snapshot and query_selector. It names the alternative tools that accept the resulting frame index or id, and states that index 0 is always the main frame. This gives the agent a complete routing decision without further 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 readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: collection is automatic (no enabling needed), only the most recent 1000 requests are retained, and each URL is truncated to 150 characters. This helps agents avoid misinterpreting truncated 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?

The description is compact and front-loaded: the first sentence states the core purpose, followed by critical context (automatic collection, main use case, retention/truncation limits). Every sentence contributes meaningful information 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?

Given the output schema exists and all parameters are documented, the description covers what an agent needs: automatic collection, the main use case with a clear workflow, and important limitations (1000-request cap, URL truncation). Nothing critical is missing for correct usage.

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 parameters are documented. The description adds marginal value by recommending a specific filter value for a common use case, but it doesn't introduce semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('network requests the selected page has made'), which is distinct from sibling tools like get_network_request (reads a single request's body). It clearly identifies the scope (selected page) and purpose.

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

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

Provides explicit when-to-use guidance: identifies the main use case (finding a page's JSON API calls) and prescribes the exact filter resource_types=['XHR','Fetch'] and the follow-up step of passing the id to get_network_request. Also distinguishes from console capture by noting collection is automatic.

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 readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond that: indices are positional and shift, the selected page is marked, and the CDP targetId remains stable across tab open/close events. No contradiction with annotations.

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 longer than strictly necessary but every paragraph adds useful information: output contents, index semantics, selected-page behavior, and targetId stability. There is no filler, though it could be tightened.

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

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

Given the output schema exists and the tool has only one optional parameter, the description is complete. It covers what the tool lists, how to interpret the index, how selection works, and the distinction between transient indices and stable CDP targetIds.

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 browser parameter is already fully documented in the schema. The description does not add anything about the browser parameter, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: "List every open browser tab with its index, URL and title." This clearly distinguishes list_pages from sibling tools like list_browsers (browsers) and list_sessions (sessions) by explicitly targeting tabs/pages.

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

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

The description gives clear operational guidance: the returned index is the page_id used by select_page and close_page, and indices should be re-read rather than reused because they shift. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.

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

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

Annotations already establish readOnly and non-destructive behavior. The description adds useful lifecycle context: the default profile is ephemeral and deleted at session end, while persistent profiles retain cookies, logins, and extensions across sessions. It does not fully clarify how the active ephemeral profile is represented in the response, but the output schema likely covers that.

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 first sentence front-loads the tool's purpose, and subsequent paragraphs provide relevant conceptual context and sibling routing without filler. Every sentence earns its place.

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

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

For a simple read-only listing tool with one optional parameter, the description is complete enough. It explains what is listed, what active means in the profile lifecycle, and how persistent profiles relate to the sibling profile-management tools, while the schema and output schema cover the remaining mechanical details.

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

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

The input schema already describes the browser parameter at 100% coverage, including its default and the parallel-agents caveat. The description adds no further parameter-specific meaning, so the baseline score 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 first sentence states an exact action and resource: list persistent Chrome profiles and show which one is active. It distinguishes persistent profiles from the ephemeral default profile and is clearly distinct from related tools like list_browsers and create_profile.

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

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

The description gives clear context around when persistent profiles matter and names the related operations create_profile, use_profile, and use_temp_profile. It does not explicitly state when not to use list_profiles or how to choose between it and sibling listing tools, so it stops short of full 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds genuine value beyond that: sessions persist in ~/.nodriver-mcp/sessions/, are never cleaned up automatically, and accumulate over time — a meaningful behavioral disclosure about side effects of the feature (disk growth, stale logins) that annotations do not express.

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 filler: the core action is front-loaded in the first sentence, the output's purpose follows in the second, and the storage/retention context in the third. Every sentence earns its place.

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

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

For a simple read-only listing tool with one documented optional parameter and an output schema, the description covers everything an agent needs: what is listed, ordering, how the result feeds a sibling workflow, and the storage location. Return-value details are already handled by the output schema, so nothing critical 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 description coverage is 100%: the single optional 'browser' parameter is already fully documented in the schema, including guidance on parallel agents needing distinct names. The description adds no parameter-level detail, but per the rubric, the baseline of 3 applies 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 opens with a specific verb+resource ('List saved session files') and further specifies exact fields (name, save time, contents), ordering (newest first), and the storage location. It also names the consumer of its output (load_session), which clearly separates it from siblings like save_session and load_session 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?

The description gives clear usage context by stating the output is 'the filename to hand to load_session', effectively describing the save/load workflow. However, it never explicitly names alternatives or states when NOT to use this tool (e.g., versus list_pages or list_browsers), so it stops short of a 5.

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

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

The description discloses several behavioral nuances beyond the annotations: it navigates to the saved origin, reloads the page, skips invalid cookies instead of failing, and reports how many were restored. It also notes that expired tokens still leave the user logged out. These details are not present in the annotations (which only set readOnlyHint=false, destructiveHint=false, etc.) and provide essential context for the agent about side effects and limitations.

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 slightly long (about four sentences) but each sentence adds value: purpose, usage context, process, and behavioral caveats. The most important information is front-loaded, and there is no fluff. It earns a 4 for being well-organized and efficient, though not as terse as the highest tier.

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

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

For a tool with an output schema and complex side effects (navigation, reload, selective restoration), the description covers all critical aspects an agent needs to know: what to do, how it works, what to expect (count of restored cookies), and potential failure modes (expired tokens). It also implicitly addresses prerequisites by referencing saved sessions and list_sessions. Nothing essential 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?

The input schema already describes all three parameters with full coverage (100%), so the description doesn't need to add parameter-level detail. It does reinforce the 'filename' parameter by mentioning it as shown by list_sessions, and the browser parameter is already explained in the schema. However, the description doesn't add significant meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description opens with a precise verb and resource: 'Restore cookies and localStorage from a saved session file.' It also states the intended purpose ('arrive already logged in') which distinguishes it from sibling tools like save_session, get_cookies, or set_cookie. The behavior is clearly scoped to session restoration, making it easy to identify when to use.

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

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

The description explicitly recommends using this tool 'at the start of a run to arrive already logged in,' giving clear when-to-use guidance. It also warns about expired tokens and advises checking the page afterward. It does not explicitly name alternative tools for other scenarios, but the context is sufficient for an agent to infer that this is for restoring a saved session rather than setting individual cookies or storage values.

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 indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral details: the master switch governs both installed and unpacked extensions, every action except 'list' restarts the browser (from schema), and official Chrome ignores --load-extension since v137. It also discloses the persistence limitation. No contradiction with annotations.

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 well-organized into three paragraphs: purpose, mechanism explanation, and platform limitations. Each sentence carries weight, avoiding redundancy. The front-loaded purpose statement and the clear breakdown of behaviors make it easy for an agent to grasp the tool's capabilities quickly.

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

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

Given the tool's complexity (multiple actions, platform-specific behavior, persistence caveats), the description covers all critical aspects: the master switch, load restrictions, persistence, and browser independence. The output schema exists and parameter descriptions are thorough, so nothing essential 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 coverage is 100%, so parameters are already documented. The description enriches understanding by explaining the interplay between 'action' values and the master switch, and clarifies the 'browser' parameter's independence. For instance, it explains that 'load' implies 'on', which is not explicitly stated in the schema description for 'action'. This adds semantic value 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?

The description opens with 'List, enable, disable or load Chrome extensions' – a clear verb+resource that immediately states the tool's function. It also explains the two mechanisms (master switch and unpacked loading), which distinguishes the tool's behavior from a simple toggle. No sibling tool covers extensions, so differentiation is inherent.

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

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

The description provides explicit guidance on when to use which action: it states that 'load' only works on Chromium or Chrome for Testing, and on official Chrome the alternative path is to install from Web Store and use 'on'. It also explains persistence requirements, telling the agent to use a persistent profile for extensions to survive. This is concrete when-to-use information.

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 (readOnlyHint=false, destructiveHint=false, etc.), the description discloses important side effects: navigating rotates collected logs, moves previous entries into preserved history (last 3 kept), and makes them reachable via include_preserved_* on list tools. It also explains the return value and that the tool reuses the current tab. No contradiction with annotations.

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 front-loaded with the core purpose in the first sentence and then organized into short, focused paragraphs covering side effects, device timing, and return behavior. Every sentence adds distinct value; there is no filler or repetition of schema content.

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

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

For a tool with 8 parameters and an output schema, the description is complete: it states the action, side effects on logs, device timing, return value, and tab reuse. The schema already documents all parameters in detail, so the description does not need to repeat them. The agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter nuance beyond the schema: it explains that passing device applies emulation before the request is sent, affecting the first byte seen by the server, which is not stated in the schema's device description. This helps the agent decide when to use the device parameter vs. calling emulate_device separately.

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: 'Navigate the selected page — load a URL, or go back, forward or reload.' It clearly enumerates the four navigation modes and distinguishes itself from siblings by stating 'This reuses the current tab; use new_page to open an additional one' and contrasting with emulate_device for device emulation timing.

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

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

The description gives explicit when-to-use guidance: 'Passing device applies the emulation before the request is sent... calling emulate_device afterwards is too late for that first request' tells the agent when to prefer this tool's device parameter over the sibling emulate_device. It also says 'use new_page to open an additional one,' clearly routing to the alternative when a new tab is needed.

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 this as a mutating (readOnlyHint=false) and world-opening (openWorldHint=true) action. The description goes well beyond that by disclosing tab-reuse behavior, the fact that a blank tab is left alone, isolated contexts getting their own target, the selection side-effect unless background is set, and the timing of device emulation. These are concrete behavioral traits an agent needs to anticipate side effects correctly, with no contradiction to the annotations.

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

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

The description is a single well-structured paragraph, with the primary purpose in the first sentence and each subsequent sentence adding distinct value (tab reuse, selection behavior, device emulation timing). No filler or redundancy; every clause contributes to understanding when and how to use the 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?

Given the tool's complexity (six parameters, side effects on selection, isolation, and emulation timing) and the presence of an output schema, the description covers all essential behavioral nuances. It explains the startup-tab handling, background behavior, isolated-context targeting, and device emulation advantage. The only parameters not mentioned (timeout, browser) are self-explanatory and fully documented in the schema, so nothing critical 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% for all six parameters, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that passing device applies emulation before the first real request (a timing nuance not in the schema), that background controls selection behavior for subsequent calls, and that isolated_context always gets its own target. These enrich the parameter semantics without restating the schema, earning a 4.

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 the core action clearly: 'Open a new browser tab and load a URL.' It distinguishes itself from sibling tools like navigate_page (which acts on an existing page) and select_page (which selects a page) by focusing on creating a new tab. It also explains the startup-tab reuse behavior, making the tool's purpose precise and unambiguous.

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

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

The description gives explicit guidance on when to use this tool: it is the way to open a new tab, with specific notes on the first call reusing the startup tab and the background parameter affecting selection. It also contrasts with emulate_device, stating that passing device here gives emulation from the first byte, which calling emulate_device afterwards cannot achieve — a clear when-not condition. This helps an agent choose between opening a page and emulating a device.

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 the sparse annotations (readOnlyHint: false, destructiveHint: false) by disclosing captured timeline categories, the ~5s recording window, the single-trace-at-a-time constraint, and the output behavior (event count vs raw JSON). This is rich, useful behavioral context that the annotations do not provide, and there is no contradiction.

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 tightly structured: an opening purpose sentence, a short list of captured categories, a paragraph on default behavior and concurrency, and a note about file_path and output format. Every sentence earns its place; there is no fluff or repetition of schema details.

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

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

Given four optional parameters, an output schema, and the presence of a sibling performance_stop_trace, this description is complete: it covers trace content, default timing, concurrency limits, file output behavior, and how to load the result. An agent has everything needed to invoke the tool correctly and interpret its 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explicitly explaining the consequences of passing file_path ('keep the data' vs 'just an event count') and by reinforcing the meaning of the defaults (reload + auto_stop) in context. That extra guidance justifies a score above baseline.

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

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

The description opens with a specific verb and resource: 'Record a Chrome performance trace of page load or interaction.' It clearly distinguishes this from sibling tools (e.g., performance_stop_trace) by stating it starts the trace, and it lists what the trace captures. An agent can tell exactly what this tool does 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 gives clear context on when to use the tool: for profiling page load or interaction, and it explains the default self-contained behavior (reload + auto_stop) plus the option to pass file_path to keep data. It doesn't explicitly name alternatives or state when not to use it, but the usage context is strong enough that an agent would not confuse it with other 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?

Adds real behavioral context beyond the annotations: the error condition when the trace already ended and the 30-second flush wait. These are exactly the kind of runtime behaviors descriptions should disclose. No contradiction with annotations.

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, each earning its place: core action, usage condition/error, and timeout behavior. Front-loaded with the primary purpose and 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?

Complete for the tool's complexity: purpose, when-to-call, error case, and blocking behavior are all covered, and the output schema handles return-value details. Only minor extras like resource implications are 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 the schema already fully documents both parameters. The description contributes no param-level detail, but none is needed given the baseline-3 rule 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 (stop) and resource (performance trace), plus the consequence (collect its data). It clearly differs from the sibling performance_start_trace and the first line makes the action unmistakable.

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 sibling tool, the triggering condition (auto_stop=false), and the failure mode when used incorrectly ('returns an error'). An agent knows exactly when to call this vs. when not to, with nothing 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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, which establish the tool is a non-destructive mutation. The description adds useful behavioral context: focus handling (falls back to document body) and modifier bitmask behavior for chords. It does not mention potential side effects like navigation triggers, but annotations already set expectations for safety.

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

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

The description is three short paragraphs with zero fluff. It front-loads the purpose, then explains focus behavior, then gives alternatives. Every sentence earns its place, and the structure is scannable.

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

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

Given the tool's complexity (keyboard shortcuts, focus dependence, multiple parameters) and rich schema plus output schema, the description covers all critical aspects: focus prerequisite, modifier chord behavior, and clear routing to alternatives. An agent can call it correctly without further 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 the parameter descriptions are already detailed (key lists examples and modifiers, browser explains independent Chrome instances, include_snapshot explains its trade-off). The description adds focus and chord behavior, but that is usage guidance rather than parameter semantics. With full schema coverage, the description does not need to compensate.

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

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

The description clearly states the tool sends a key press or keyboard shortcut to the page, identifying the verb and resource. It distinguishes itself from fill and type_text by explicitly noting 'this tool is for single keys and shortcuts,' which separates it from sibling tools that handle text entry.

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

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

The description gives explicit when-to-use guidance: it targets the currently focused element, so the agent knows to click or fill first. It also names alternatives (fill, type_text) and explains when not to use this tool, covering exclusions clearly.

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 (readOnlyHint=true, destructiveHint=false), the description adds significant behavioral detail: compact listing only, no uids, inability to drive clicks, 200-character text truncation, and frame-isolated-world semantics. Nothing contradicts the annotations.

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, information-dense sentences, each earning its place: core function, use case, limitation with alternatives, and truncation behavior. The most decision-relevant constraints are 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?

Given the output schema exists and the input schema is fully described, the prose covers all necessary decision factors: when to use, what it returns, what it cannot do, and a critical output limitation. An agent has enough to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema already provides strong parameter descriptions, including selector syntax limitations, frame isolation, browser naming, and limit semantics. The tool description itself does not add further parameter-level detail.

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

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

The description states a specific verb and resource: 'Find elements by CSS selector; list their tag, text, href, id and class.' It clearly distinguishes the tool from snapshot-based alternatives by emphasizing compact output, no uids, and repeated-structure extraction.

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

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

The description explicitly explains when to use this tool ('efficient way to pull a repeated structure off a page... without paying for a full snapshot') and when not to ('It yields no uids, so it cannot drive clicks'), with concrete alternatives: take_snapshot or evaluate_script. This is exemplary usage 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?

The description details the full scope of the reset, listing network throttling, CPU throttling, geolocation, user agent, client hints, color scheme, viewport, device pixel ratio, page scale, and touch emulation. It also discloses the CDP click restoration behavior. These specifics go well beyond the annotations (idempotentHint, destructiveHint) and give the agent a precise model of the tool's effects.

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

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

The description is tightly structured: a one-line purpose, a list of reset items, and a usage note. Every sentence contributes new information—no fluff or repetition. The most critical detail (what it resets) is front-loaded, and the usage guidance is placed where it naturally follows.

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

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

For a tool that resets many emulation categories, the description enumerates them all, making the tool's effect fully transparent. It also provides usage context and a side effect. The presence of an output schema means return values don't need explanation, and the parameter is covered by the schema. Nothing essential 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?

The single parameter 'browser' is fully documented in the schema with its own description covering default behavior and parallel-agent usage. The tool description adds no extra semantic detail about the parameter, but since schema coverage is 100%, a baseline of 3 is appropriate. The description's omission is not a gap because the schema already handles 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 uses a specific verb ('Clear') and resource ('every emulation override'), then enumerates the exact overrides it resets. It distinguishes itself from siblings like emulate and emulate_device by explicitly stating it is the counterpart that reverts them. This leaves no ambiguity about what the tool does.

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

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

It explicitly states when to use it: 'Use after emulate or emulate_device to make the page behave like ordinary desktop Chrome again.' It also adds a specific side effect ('Turning touch emulation off here also restores trusted CDP clicks'), which informs the agent of an additional reason to call it. No exclusions are needed since the tool's purpose is narrowly scoped.

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