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

Beyond annotations, the description discloses session-scoped persistence across navigations, the reset mechanism, and specific side effects on stylesheet-blocking for geometry-dependent operations. This enriches the idempotentHint with concrete behavioral expectations and potential failure modes.

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, each serving a distinct purpose: primary function, use-case benefit, and side-effect/scope warning. Every sentence earns its place with no repetition or filler, and the most important information is front-loaded.

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

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

With a single parameter fully described in the schema and an output schema present, the description covers behavior, side effects, scope, and reset, making it fully actionable for an agent. No additional return-value documentation is needed given the output 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?

The schema already provides 100% coverage, including recommended enum combinations and unblock semantics. The description adds value by explaining why stylesheet blocking breaks layout and reinforcing the trade-off, going slightly beyond the schema without duplicating it.

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

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

The description clearly states the tool's function: blocking images, fonts, stylesheets, or media to speed up page loads. It distinguishes itself from sibling tools by specifying the resource types and the performance motivation, 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 provides explicit when-to-use guidance (media-heavy pages, metered/proxied connections) and when-not-to-use (when layout-dependent behavior is needed, listing affected tools like click_at and wait_for_selector). It also explains how to reset via calling with no types, giving clear operational boundaries.

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 beyond the annotations by explaining the exact action performed ('Advanced -> Proceed click') and the behavior that it has no effect on other pages. This discloses the tool's scope and side effects, complementing the annotations without 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?

The description is concise and front-loaded, with the core action in the first sentence. Subsequent sentences provide necessary context and exclusions without any fluff. 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 zero-parameter tool with a simple action, the description is complete: it states what it does, when to use it, the implementation detail, and the non-effect on other page types. No gaps remain for an agent to correctly select and invoke the 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 tool has zero parameters, so the description carries no parameter burden. The baseline for 0 parameters is 4, and the description adds no unnecessary detail about parameters, which is appropriate.

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

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

The description names the specific action ('Click through Chrome's "Your connection is not private" interstitial') and clearly distinguishes it from generic click tools by scoping it to SSL/certificate warning pages. This is a specific verb+resource pairing that 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?

Explicitly states when to use the tool ('when a navigation lands on an SSL/certificate warning page') and when not to ('Has no effect on any other kind of page'). It explains the problem (snapshot shows warning page instead of expected content) and what the tool accomplishes, providing clear context and an exclusion.

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

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

Goes beyond annotations by disclosing the opencv-python dependency (returns error without it), the visual click mechanism, and the fact that many challenges clear on their own. This adds valuable behavioral context without contradicting 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?

Three sentences, front-loaded with purpose, then usage context, then dependencies/alternatives. Every sentence provides essential information with no waste.

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

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

For a zero-param tool with an output schema, the description covers prerequisites (opencv), usage scenarios, and behavior. It also suggests a fallback strategy (wait_for), making it comprehensive for the tool's complexity.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none, and it doesn't add extraneous parameter info.

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

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

The description clearly states the tool's purpose: 'Attempt to solve a Cloudflare Verify you are human challenge.' It uses a specific verb and resource, and distinguishes itself from sibling tools by targeting Cloudflare interstitials specifically.

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 states when to use: 'Use when a page is stuck on a Cloudflare interstitial — a checkbox widget, or Checking your browser before accessing.' It also recommends wait_for as an alternative first try, providing clear usage 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?

The description goes beyond the destructiveHint and idempotentHint annotations by explaining the scope (browser-wide, not per site/tab), the lack of undo, and the fact that localStorage is untouched. This gives the agent critical context 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?

Three short, focused paragraphs. The first sentence states the action, the second clarifies scope and consequences, and the third provides use cases and a caveat. Every sentence earns its place; no 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 no-parameter tool, the description covers all essential aspects: what it does, scope, irreversibility, recovery path, and edge case (localStorage). With an output schema present and no parameters, this is fully complete.

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

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

The tool has zero parameters, so the schema fully covers parameter semantics. The description adds behavioral context rather than parameter details, which is appropriate. The baseline of 4 applies here.

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

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

The description clearly states 'Delete every cookie in the browser' with a specific verb and resource. It distinguishes itself from per-site or per-tab tools and from related siblings like get_cookies or set_cookie by emphasizing the browser-wide scope.

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 use cases: testing first-time-visitor flow or resetting consent banner decisions. Also provides an alternative for recovery via load_session, guiding the agent when to use this tool versus when to use a session restoration 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?

The description discloses rich behavioral traits beyond the annotations: it sends real CDP input events with isTrusted=true, explains the two fallback scenarios and their consequences, notes that every step is bounded at 10s, and states that fallbacks are never silent. This is exactly the kind of context annotations do not provide. No contradiction exists.

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, then delivers usage guidance and behavioral detail in an organized manner. Every sentence earns its place—there is no filler or repetition. The length is justified by the technical nuance it conveys.

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 3 parameters and an output schema, the description covers all essential aspects: purpose, alternative tool, fallback behavior, timing constraints, and error recovery. The presence of an output schema means return values need not be described, so nothing critical is missing. The description is fully self-sufficient for an agent to invoke the tool correctly.

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

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

Although schema coverage is 100%, the description adds significant meaning beyond the raw parameter definitions. It explains why uids are reliable, how to handle 'unknown uid' with a fresh snapshot, and the trade-off of include_snapshot (saves a round trip at cost of larger response). This meaningfully enhances an agent's ability to use the parameters correctly.

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

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

The description opens with a specific verb and resource: 'Click an element addressed by its snapshot uid.' It clearly distinguishes this tool from the sibling click_at by stating it is preferred and explaining why (uid survives layout shifts). The purpose is immediately 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 explicitly says to prefer this over click_at, provides the rationale, and details the specific situations (touch-emulated target, timeout/error) that force a scripted fallback. This gives clear when-to-use and when-not-to-use guidance, going beyond vague hints.

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 that coordinate clicks are not robust against layout shifts, use real CDP events with the same scripted fallback and 10s bound as `click`, and that coordinates are in CSS pixels ignoring device pixel ratio. These details extend well beyond the sparse annotations and provide critical execution context.

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

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

The description is well-structured in four tight paragraphs, each addressing a specific aspect: core function, alternative usage, coordinate constraints, and behavioral equivalence. No redundant or filler sentences, and the most important information is front-loaded.

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

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

For a simple click action, the description covers when to use it, how it differs from `click`, coordinate system details, viewport requirements, and event behavior. With an output schema present, this is fully complete for an agent to invoke correctly without additional assumptions.

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 describes all 4 parameters (100% coverage), so baseline is 3. The description adds meaningful semantics for x/y by stating they are in CSS pixels, viewport-relative, and matching emulate/resize_page, plus the viewport constraint. These additions clarify the coordinate system beyond the schema, though other parameters are not additionally addressed.

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 'Click a raw viewport coordinate instead of an element,' clearly stating the verb, resource, and distinguishing from `click` which targets elements. It further clarifies use cases for surfaces without addressable elements, such as canvases, maps, and video players.

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 instructs to use `click` with a uid when the target appears in a snapshot, and reserves coordinates for non-element surfaces. It also provides a prerequisite: scroll into view if the point is outside the viewport, naming `scroll_page` and `scroll_to_selector` as alternatives.

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

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

The description discloses critical behavioral traits beyond the destructiveHint annotation: it closes every tab, sacrifices all browser state on ephemeral profiles, preserves data on persistent profiles, and automatically relaunches on the next tool call. This is rich, honest behavioral context that fully aligns with and expands upon 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 concise and well-structured. Every sentence serves a purpose: the first gives the core action, the second differentiates from close_page and explains the relaunch behavior, and the third covers data persistence and the save_session recommendation. No word is wasted, and the structure facilitates quick scanning.

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 simplicity (no parameters), the description is complete. It explains the tool's effect, its side effects on different profiles, when to use it, and the relaunch behavior. The presence of an output schema reduces the need to describe return values, and the description covers all necessary contextual aspects.

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

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

The tool has zero parameters, so parameter semantics are inherently satisfied. The description does not need to explain any parameter details, and the schema coverage is 100% by vacuity. A baseline of 4 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, unambiguous action: 'Quit Chrome entirely, closing every tab.' It clearly identifies the resource (Chrome browser) and the scope (all tabs), and explicitly contrasts itself with the sibling tool close_page, making its unique purpose obvious.

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 over close_page, states that it's the mechanism to apply pending launch flags, and advises saving session data before use on ephemeral profiles. These are clear, actionable usage guidelines with direct alternatives and prerequisites.

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

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

Beyond the destructiveHint annotation, the description reveals critical behavioral traits: the last-tab restriction, selection clearing with fallback to the most recently opened tab, and index shifting. It also instructs the user to re-read remaining page indices from the response, preventing stale references. This is rich, actionable 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 concise and well-structured: a one-sentence purpose, then a caveat with an alternative, then an important behavioral note about selection, and finally a critical instruction about return values. Every sentence contributes value with no redundancy or fluff.

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

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

For a simple tool with a single optional parameter, the description covers all essential aspects: the action, edge cases (last tab), side effects on selection, and return semantics. The availability of an output schema reduces the need to detail the exact return format, but the description still mentions the key behavior of returning remaining pages. This is complete for the tool's complexity.

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

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

The schema already provides 100% coverage for page_id, including the -1 default and its meaning. The description goes further by noting that indices shift after a close, implying that page_id values become stale and must be refreshed from the response. This adds semantic value beyond the schema, earning a 4 rather than a baseline 3.

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

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

The description opens with 'Close a single browser tab,' which is a specific verb-resource pair that immediately distinguishes this from close_browser. It also clarifies the constraint that the last tab cannot be closed, reinforcing the tool's exact scope. This clearly differentiates it from related 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 explicitly states when to use an alternative: 'The last remaining tab cannot be closed — use close_browser to shut Chrome down entirely.' This provides an explicit exclusion and directs users to the correct sibling tool. Additionally, it explains the selection-fallback behavior, giving clear context for 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?

Beyond annotations, the description discloses key behavioral traits: 'nothing changes until you activate it', 'An existing profile of the same name is left untouched rather than overwritten', storage path under ~/.nodriver-mcp/profiles/<name>, and the one-instance-per-profile constraint. These add meaningful context without contradicting 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 four sentences, front-loaded with a crisp definition, followed by high-value context (persistence, alternatives, side effects, path, concurrency). Every sentence contributes new information, with no fluff 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?

Given the tool's moderate complexity, annotated metadata, and fully described schema, the description covers all necessary aspects: purpose, alternative tools, side effects, safety, storage location, and usage constraints. No major gaps remain.

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 parameters have detailed descriptions already. The description adds extra context beyond the schema by explaining that profiles live at a specific filesystem path and that activation can happen later via use_profile, which enriches understanding of the `activate` parameter. However, the schema already covers the immediate meaning of both parameters, so not a 5.

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

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

The description opens with a specific verb and resource: 'Create a named persistent Chrome profile — a reusable user-data dir.' It clearly distinguishes this from siblings by calling it 'the sturdier alternative to save_session / load_session' and by explaining persistent profiles keep cookies/logins between runs. This makes the tool's 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?

Explicitly positions the tool against alternatives: 'It is the sturdier alternative to save_session / load_session.' It also explains that creation alone is harmless and that activation can happen later via use_profile, giving clear context for when to use this tool versus siblings. The concurrency warning ('Only one browser instance can use a given profile at a time') provides a practical when-not/limitation.

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 destructiveHint annotation by detailing exactly what is removed (cookies, logins, history, extensions) and confirming there is no undo. It also discloses the active profile constraint, which is critical for safe invocation.

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, purposeful sentences. It front-loads the main action and then adds necessary warnings without any fluff or repetition.

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

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

Given the destructive nature, the annotations, the output schema, and the single well-documented parameter, the description fully covers the essential behavior, the irreversible consequences, and a key edge case. Nothing important 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 schema already provides 100% coverage for the single 'name' parameter, including a description referencing list_profiles. The tool description adds no additional parameter semantics, 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 description clearly states the action ('Permanently delete'), the resource ('persistent Chrome profile directory'), and emphasizes irreversibility. It distinguishes from siblings like create_profile/use_profile by highlighting permanence.

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 explicit note that the active profile cannot be deleted and the instruction to switch away with use_temp_profile first provides practical usage context and names an alternative tool. While it doesn't exhaustively cover all edge cases, it gives clear actionable 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 idempotentHint annotation, the description explains the underlying mechanism (turns off CDP Runtime domain), the anti-bot detection benefit (quieter, harder-to-detect default), and the key side effect that 'Messages already collected stay readable; only new ones stop arriving.' This is exactly the kind of behavioral context that helps an agent predict outcomes.

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

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

The description is three tight sentences, front-loaded with the main action, then providing rationale and a side effect. Every sentence earns its place—no fluff, no redundant restating of the title. It is a model of concise yet informative writing.

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

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

For a zero-parameter tool with an output schema, the description provides all necessary context: what it does, when to use it, why it matters, and what happens to collected data. It is fully complete for the tool's complexity and leaves no major behavioral questions unanswered.

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 baseline is 4. The description adds no parameter-level details because none are needed. It doesn't need to compensate for any schema gaps since the schema is empty and coverage is 100%.

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: 'Stop capturing console output on the current page.' This clearly distinguishes it from sibling tools like enable_console_collection and list_console_messages. The purpose is unambiguous and action-oriented.

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

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

It provides clear context for when to use: 'once you are finished debugging and the page still has anti-bot checks ahead of it.' This implies when it's appropriate, but it doesn't explicitly mention alternatives or exclusionary cases (e.g., when you still need new messages). Still, the context is strong enough to guide the agent.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses a key limitation: some JS libraries need intermediate mousemove events that this tool does not emit. It also warns about silent failures and suggests a workaround. This is valuable behavioral context not inferable from 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 concise yet rich: three short paragraphs cover the action, a prerequisite, and a behavioral caveat with a workaround. Every sentence serves a distinct purpose; no filler or 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 complicated interaction tool like drag-and-drop, the description is complete: it covers prerequisites, supported scenarios, limitations, and alternatives. The input schema and output schema handle parameter details and return values, leaving the description to add critical operational context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds slight semantic value by clarifying that 'both uids must come from the same take_snapshot,' emphasizing a constraint not made explicit in the schema (which only says 'from the most recent take_snapshot' for each). This helps disambiguate the relationship between from_uid and to_uid.

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 drag-and-drop action: 'Drag one element onto another (press, move, release).' This verb+resource phrasing distinguishes it from sibling tools like click, hover, and click_at.

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 explains when to use the tool (for native HTML5 drag-and-drop and mouse-driven sortable lists) and provides an alternative when it fails: 'drive it manually with click_at and press_key instead.' It also notes the prerequisite that both uids come from the same take_snapshot.

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 (idempotentHint=true, destructiveHint=false), the description discloses important behavioral traits: persistence across navigations, the independent-parameter behavior, and the concrete side effect that enabling `touch` changes `click` behavior (falls back to scripted path with isTrusted=false). It also warns about UA client hints not being touched by the user_agent parameter. This adds meaningful context beyond what 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 appropriately sized: four sentences, each serving a distinct purpose—listing capabilities, stating scope and parameter usage, mentioning the alternative tool, and warning about a behavioral interaction. No redundant or vague phrasing; the most important information is front-loaded.

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

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

With 6 fully schema-described parameters, an output schema present, and annotations covering mutability and idempotence, the description still adds crucial context: persistence, how to reset via reset_emulation, the explicit alternative emulate_device, and the touch-click caveat. This is sufficient for an agent to select and safely invoke the tool without additional external knowledge.

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 that 'Every parameter is independent — pass only what you want to change, leave the rest at their defaults,' which clarifies the default-value semantics beyond the schema. It also highlights the interaction between the viewport's `touch` flag and click behavior, which is not evident from the schema alone. These additions justify a 4, though the schema already provides thorough descriptions for each 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 a specific verb and the list of emulatable resources: 'Emulate network, CPU, geolocation, user agent, color scheme or viewport.' It clearly distinguishes from the sibling tool emulate_device by explicitly naming it as the alternative for real phone/tablet emulation, and also mentions reset_emulation for clearing the 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 gives explicit when-to-use guidance: 'To emulate a real phone or tablet, use emulate_device instead' and explains why (coherent set of user agent, client hints, viewport, DPR, touch). It also states the scope ('Applies to the selected page and persists across navigations until reset_emulation') and how to use parameters independently with defaults.

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 rich behavioral details beyond annotations: all signals are set together to avoid contradictions, ipad_air deliberately reports desktop-class Safari with touch and no client hints, emulation survives navigation, and passing `device` to new_page/navigate_page is required for first-request signals. This complements the idempotentHint and non-destructive 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 well-structured and front-loaded: a one-sentence purpose, then usage justification, preset details, and scope/undo notes. Each sentence earns its place; no filler or 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 tool with 5 params, an output schema, and good annotations, the description covers the key contextual aspects: what the preset includes, when to use an alternative, page-scope behavior, and how to undo. The remaining parameter semantics are fully handled by 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% with detailed parameter descriptions, so the baseline is 3. The description adds value by explaining what 'internally consistent' means (why presets matter) and elaborating on the ipad_air preset's specific behavior, which aids parameter selection beyond the raw schema.

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

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

The description 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 emphasizing preset-based consistency and positioning itself as the preferred approach for mobile work.

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 states when to use this tool ('Preferred over assembling `emulate` parameters by hand for mobile work') and gives concrete alternatives: use `new_page` or `navigate_page` for first-request signals, and `reset_emulation` to undo. This offers clear decision guidance versus siblings.

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

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

Beyond the annotations (idempotentHint=true, readOnlyHint=false), the description discloses significant behavioral context: it enables the CDP Runtime domain, explains why it is opt-in (anti-bot scripts probe for it), and notes that it applies per page. This adds value beyond what annotations provide and helps the agent understand side effects and stealth implications.

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-structured: the first sentence gives the core purpose, followed by short, informative sentences about prerequisites, rationale for opt-in, and per-page behavior. Every sentence earns its place; no filler or 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 tool with no parameters and an output schema, the description covers all necessary context: when to call it, its relationship to related tools, why it is opt-in, and per-page behavior. The output schema handles return values, so no additional return explanation is needed.

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 has zero parameters, so the description cannot add parameter-specific meaning. Per the baseline rule for 0 params, a score of 4 is appropriate. The description focuses on behavior and prerequisites, which is all that is needed here.

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

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

The description clearly states the tool's action and resource: 'Start capturing console output on the current page.' This is a specific verb+resource construction that immediately distinguishes it from sibling tools like list_console_messages, get_console_message, and disable_console_collection.

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 usage guidance: 'Call this before list_console_messages or get_console_message' and explains the alternative (network capture is always on). It also specifies when not to use it (when stealth matters) and mentions the companion disable_console_collection for cleanup. Additionally, it clarifies the per-page scope.

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 substantial behavioral detail beyond annotations: runs in the main world, args become live DOM element references, return values must be JSON-serialisable, async functions are awaited, errors are returned as strings, and console.log output is not captured. These are non-obvious runtime behaviors that an agent needs to know, and they do not contradict the provided 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 four sentences, front-loaded with the core purpose, followed by usage context and critical behaviors. Each sentence carries distinct, necessary information with no filler or redundancy, making it efficient and 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 tool with only 2 parameters and full schema coverage, the description covers all essential aspects: invocation mode, argument semantics, return serialization constraints, async handling, error behavior, and a limitation (console.log not captured). With an output schema also present, nothing important is left unexplained.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operational context: args resolve to DOM nodes rather than strings, page-level vs. element-scoped execution, and the requirement to map DOM nodes to plain values in the return. This supplements the schema's already-solid parameter descriptions with practical usage nuance.

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

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

The description clearly identifies the tool as executing JavaScript in the page and returning JSON, and goes further by positioning it as the 'escape hatch' for scenarios other tools don't cover, with concrete examples like reading computed styles and calling page APIs. This strongly distinguishes it from sibling tools such as click, take_snapshot, and navigate_page.

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

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

It provides an explicit when-to-use heuristic: 'the escape hatch for anything the other tools do not cover', with illustrative use cases. It also explains the two invocation modes (page-level vs. element-targeted via args). It doesn't name specific alternative tools or say when not to use it, leaving a small gap in 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 thoroughly discloses behavior beyond annotations: it clears the field first, types character by character to trigger input events for React/Vue controlled components, and for <select> it selects by value and dispatches a change event. This adds significant value over the annotations (readOnlyHint=false, destructiveHint=false) and the schema, explaining the 'how' and 'why' of the tool's actions.

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 concise: a clear opening sentence, a mid-section explaining the low-level behavior, and a final sentence covering alternatives. Every sentence contributes new information without redundancy or fluff, making it highly efficient and easy to parse.

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 (interaction with controlled components) and the presence of a rich schema and output schema, the description covers all necessary context: what it does, how it does it, when to choose alternatives, and important side effects (clearing, event firing). No critical gaps remain, making it fully complete for an AI agent 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?

Schema coverage is 100%, and the parameter descriptions in the schema are already detailed (e.g., uid invalidation, select value attribute, include_snapshot behavior). The tool description does not add significant extra semantics beyond what the schema provides, so the baseline score of 3 is appropriate. There is no contradiction or missing parameter information.

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 sets the value of input, textarea, or select elements, which is specific and distinct from sibling tools like type_text and fill_form. It also explains the mechanism (clears and types) and the target element types, making the 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 explicitly provides usage guidance: 'Use type_text instead when you want to append to a focused field rather than replace its contents' and 'For several fields at once, fill_form does it in one round trip.' This clearly delineates when to use this tool versus alternatives, which is exactly what high-quality usage guidelines should do.

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 key behavioral traits beyond the annotations: fields are processed in order, a single field failure does not abort the rest, and the response reports per-uid success/error so partial fills are visible. This adds meaningful context about failure semantics and side effects that annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) do not capture.

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

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

The description is compact and front-loaded: the first sentence states the core purpose, followed by three tightly scoped sentences covering behavior, error handling, and an efficiency note. Every sentence earns its place with no redundancy or fluff.

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

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

For a tool with 2 parameters, an output schema, and clear sibling relationships, the description is thorough. It covers batch behavior, ordering considerations, partial-failure robustness, and the snapshot option's trade-off, providing enough context for an agent to select and invoke the tool correctly without needing the output 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 parameters ('elements' and 'include_snapshot') are already fully documented. The description adds no additional parameter semantics beyond reaffirming the order property of 'elements' in the prose ('Fields are processed in the order given'), which is a marginal enhancement. 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 'Fill several form fields in a single call,' a specific verb+resource that clearly identifies the tool's function. It also explicitly distinguishes itself from the sibling 'fill' by noting the batch behavior and round-trip savings, preventing 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 names 'fill' as the per-field alternative and explains the benefit of using this tool ('costs one round trip instead of one per field'). It provides context for when ordering matters (pages that reveal/enable later fields), giving clear usage context, though it does not explicitly mention 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 declare readOnlyHint=true and destructiveHint=false, so the description adds valuable context beyond that: it requires enable_console_collection to have been called, and explains that the CDP Runtime domain is disabled by default because enabling it is detectable by sites. This is meaningful operational context that goes beyond structured fields.

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

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

The description is three concise sentences, each serving a distinct purpose: primary function, comparison to sibling, and prerequisite/rationale. No fluff or redundancy; it is well-structured and front-loaded.

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

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

For a simple read-by-id tool with an output schema, the description covers the purpose, usage guidance, sibling differentiation, and prerequisite. Annotations cover safety, and the output schema covers return format. Nothing important 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 provides 100% coverage with a clear description: 'Message id, as shown in square brackets by list_console_messages.' The description simply refers to 'by id' without adding further detail, but the schema description is sufficient. Baseline 3 applies because parameter information is well-covered by the schema.

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

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

The description uses a specific verb+resource pair: 'Read one console message in full, by id.' This clearly distinguishes it from the sibling list_console_messages, which truncates messages. The first sentence alone fully defines the tool's primary function.

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 this tool: when a complete stack trace or error payload is needed because list_console_messages truncates to 200 characters. It also names the prerequisite call (enable_console_collection) and explains why, giving the agent clear context for when this tool is available.

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 declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it reads the entire cookie jar, returns full values (including live session tokens), and can be filtered by URL. This goes well beyond the annotations and gives the agent important safety-relevant information.

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, well-structured, and front-loaded with the primary purpose. Each sentence serves a purpose: the first states what it does, the second explains scope and sensitivity, and the third gives alternatives. 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 tool is simple (one optional parameter, read-only, output schema present), and the description covers all essential aspects: scope, filtering, sensitivity, and persistence alternatives. It is fully complete for an agent to select and invoke 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 covers the url parameter's meaning at 100% (including the empty-string default). The description reinforces this by explaining the 'whole jar vs filtered by url' behavior, adding a practical nuance not fully captured in the schema. It doesn't duplicate everything, but it adds useful behavioral context around the 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 clearly states a specific action ('List browser cookies') with a defined resource and the fields returned (domain, path, secure flag). It also distinguishes itself from related tools like set_cookie, clear_cookies, and get_local_storage by specifying that it reads the whole cookie jar, not just the current page.

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

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

The description gives explicit usage context: it reads all cookies unless a url is passed, and notes that outputs are sensitive. It also names specific alternatives for persistence ('save_session' and 'use_profile'), providing clear when-to-use and when-to-avoid 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 and destructiveHint=false, but the description adds valuable behavioral details: values truncated to 200 characters, per-origin scoping, empty results on about:blank, and exclusion of sessionStorage. These go beyond the annotation signals and set clear expectations.

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

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

The description is compact and well-structured: three short paragraphs each serving a distinct purpose (purpose, truncation/alternative, scoping caveat). Every sentence contributes meaningful information with no 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?

Given the zero-parameter, read-only nature and the presence of an output schema, the description covers the essential non-obvious aspects: truncation, origin scoping, about:blank behavior, and the evaluate_script alternative for full values. It is thorough and leaves no critical gaps.

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

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

The schema has zero parameters, so the baseline is 4. The description adds context about the implicit scope (current page's origin) and the truncation behavior, which is useful even though there are no formal parameters.

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

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

The description clearly states the tool's function: 'Read all localStorage entries for the current page's origin.' This uses a specific verb (Read), resource (localStorage entries), and scope (current page's origin). It also distinguishes from siblings by explicitly excluding sessionStorage and pointing to evaluate_script for reading a single full value.

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 usage guidance: 'for one entry in full use evaluate_script with ...' and warns about about:blank, implying a prerequisite of navigation. The note that sessionStorage is not included further clarifies when to use this tool versus alternatives.

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

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

The description discloses critical operational behavior beyond the annotations: inline bodies truncated at 5000 characters, file-path fallback for larger payloads, and the Chrome buffer limitation causing response bodies to disappear for long-finished requests. These details are essential for the agent to interpret results 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 tight paragraphs with the purpose in the first sentence. Every sentence earns its place, covering workflow, limits, and caveats without filler 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?

With an output schema present and annotations covering the read-only safety profile, the description still explains the key operational constraints (truncation, buffer, file paths) and positions the tool within a practical workflow. It is complete for an inspection tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter context by explaining why file paths may be needed (truncation, binary responses) and how reqid relates to list_network_requests output, enhancing the schema's dry parameter descriptions.

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

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

The description opens with "Inspect one network request: URL, method, resource type and both bodies," giving a specific verb and resource. It clearly distinguishes from the sibling list_network_requests by focusing on a single request and referencing it as the discovery step.

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 an actionable workflow: use list_network_requests to find the page's API call, then read the JSON here instead of scraping the DOM. This gives clear context for when the tool is valuable, though it does not enumerate explicit exclusions or when-not-to-use cases.

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 readOnlyHint true and destructiveHint false, and the description adds valuable behavioral context beyond that: it states that no accessibility tree is built, that text form carries no markup overhead, and that the DOM is returned as it currently stands, which explains potential async staleness. This aligns with idempotentHint false and enriches the agent's understanding of side-effect-free read 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 compact and front-loaded with the core purpose, followed by efficiency context, an async warning, and explicit sibling guidance. Every sentence earns its place; no filler or redundant repetition of schema/annotations.

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

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

For a simple read-only tool with three optional, well-documented parameters and an output schema, the description covers all necessary operational context: when to use it, the performance trade-offs, the async rendering caveat, and how it differs from siblings. There are no significant gaps.

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

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

The input schema covers 100% of parameters with detailed descriptions (format enum, file_path, max_chars). The tool description adds only marginal parameter-related context, like 'text form carries no markup overhead,' but this is more behavioral than a semantic explanation of each argument. Since schema coverage is high, 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: 'Get the page's visible text, or its full HTML.' It clearly distinguishes the tool from siblings by naming take_snapshot and query_selector as alternatives for interactive or element-specific needs, making the 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 provides explicit when-to-use guidance: it is the cheapest way to read content when not needing uids, and it advises calling wait_for or wait_for_selector first on async pages. It also names alternatives, saying to use take_snapshot for interaction and query_selector for specific elements, which is a clear yes/no usage framework.

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 important behavior beyond annotations: the blocking nature of dialogs, the error when no dialog is open, and the distinction from automatically handled beforeunload dialogs. 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?

Four concise sentences, each adding unique value: purpose, blocking behavior, error condition, and distinction from navigation dialogs. Front-loaded with the core purpose.

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 simple 2-parameter schema and provided annotations, the description covers all necessary context: when to use, behavior, error handling, and how it relates to other tools. Output schema exists, so return values need no explanation.

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

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

Schema coverage is 100% with parameter descriptions already explaining accept/dismiss and prompt_text. The description does not add further meaning to the parameters themselves, meeting the baseline for high schema 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 description uses a specific verb 'Answer' and resource 'open JavaScript dialog', explicitly listing the dialog types: alert, confirm or prompt. It clearly distinguishes from sibling tools, none of which are dialog-related.

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: 'A dialog blocks the page and every subsequent tool call until it is handled, so call this as soon as one appears.' It also gives an exclusion: beforeunload dialogs are handled by navigate_page, so this tool is for dialogs the page opens by itself.

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

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

Discloses behavioral boundaries: only moves the pointer, does not scroll, and can reveal content via include_snapshot. The annotations already indicate non-read-only and non-destructive, so the description adds useful clarifications without 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?

Three short paragraphs, front-loaded with the core action, then targeted guidance. No redundant 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?

Covers action, use cases, viewport caveat, and snapshot retrieval. The output schema handles return values, so the description is complete for an interaction tool of this scope, though it doesn't mention potential page-state changes beyond the hover-reveal behavior.

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

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

The schema covers 100% of parameters with detailed descriptions, so the tool description does not need to repeat them. The description only references include_snapshot contextually, adding no new parameter syntax; 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+resource ('Move the mouse over an element') and explicitly distinguishes from clicking and scrolling, making its purpose unmistakable. It also identifies the use case of opening hover-triggered menus, tooltips, and dropdowns.

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 the use case (hover-triggered menus/tooltips/dropdowns) and names an alternative (scroll_to_selector) for out-of-viewport elements. It also recommends include_snapshot=true when the hover changes the page, providing clear when-to-use 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, so safety is covered. The description adds valuable behavioral details beyond that: each line is prefixed with id and truncated to 200 characters, only the most recent 1000 messages are retained, and the opt-in rationale. These details help the agent set expectations without contradicting 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 four sentences, front-loaded with the main action, and each subsequent sentence earns its place by explaining prerequisites and behavioral details. There is no fluff or redundancy, making it highly concise and well-structured.

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

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

The tool has an output schema, so return values need not be spelled out. The description covers prerequisites, opt-in rationale, behavior (truncation, retention, id prefix), and points to get_console_message for full text. With only 4 optional params and an output schema, this is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add syntax or format details beyond what the schema provides, but it does add context about truncation and id use that relates to output quality. No extra param semantics are needed, so a 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 uses a specific verb+resource construction: 'List console output collected for the selected page.' It clearly identifies what the tool does and its scope. It also differentiates from siblings by referencing get_console_message for full text and implying enable_console_collection as a prerequisite, making the purpose and boundary explicit.

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

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

Explicitly states the prerequisite: 'Requires enable_console_collection first.' It also explains the consequence of not doing so ('without it this returns a reminder instead of messages') and provides reasoning (CDP Runtime domain, site detection). This gives clear when-to-use instructions and distinguishes from get_console_message by id.

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 read-only and non-destructive. The description adds critical behavioral constraints: automatic collection, retention limited to 1000 requests, URL truncation to 150 characters, and the presence of ids in square brackets. This goes beyond the annotations and helps the agent understand the tool's limits.

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 compact paragraph of four sentences. Each sentence serves a purpose: purpose, automatic collection, main use case, and retention/truncation limits. No redundant noise.

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

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

Given the tool's moderate complexity and the rich schema (5 params, all described) plus an output schema, the description covers the core purpose, usage patterns, and key behavioral limits. It also links to the companion tool get_network_request for the full workflow. 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 has 100% coverage with descriptions. The description adds usage patterns, such as the recommended resource_types filter and how to use the output id to call get_network_request. This gives the agent practical parameter guidance beyond the schema, though it doesn't elaborate on pagination (which the schema already covers).

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 clear verb ('List') and resource ('network requests the selected page has made'). It distinguishes from sibling 'get_network_request' by explaining that this tool lists requests while the other reads response bodies. The phrase 'main use is finding the JSON API a page calls' further clarifies its specific role.

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

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

The description explicitly tells the primary use case (finding JSON API calls) and how to execute it (filter with resource_types=['XHR','Fetch'], then pass id to get_network_request). It also contrasts with DOM scraping and mentions that collection is automatic, unlike console capture, guiding 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?

Annotations already mark this as read-only and non-destructive, so the safety profile is covered. The description adds valuable behavioral context: indices shift dynamically and the default page target behavior (selected page or most recent tab). This goes beyond the structured annotations and helps the agent reason about state changes.

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, each serving a distinct purpose: what it returns, the dynamic index warning, and the page-selection behavior. No wasted words; information density is high 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?

With no parameters, presence of an output schema, and strong annotations, the description fully covers the tool's behavior. It explains the output fields, index semantics, and interaction with other tools, making it complete for an agent 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 tool has zero parameters, so there is no parameter burden on the description. The baseline for no parameters is 4, and the description appropriately omits param details since none exist. No unnecessary parameter information is needed.

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 'List' with a clear output scope: 'every open browser tab with its index, URL and title.' It distinguishes itself from sibling tools by focusing solely on tab enumeration, and even connects the index to select_page/close_page, making the purpose 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?

Provides clear usage context by explaining that indices are positional and shift, so the agent should re-read rather than reuse stale indices. It also clarifies how tools act on the selected page or the most recent tab. However, it does not explicitly compare against alternatives like get_page_content or take_snapshot, though the purpose makes the use case fairly 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is to add context. It does so by explaining the default ephemeral temp profile and that persistent profiles preserve cookies, logins, and extensions across sessions. This adds meaningful 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 three short paragraphs; the first sentence states the core function, and the subsequent sentences provide essential context about ephemeral vs persistent profiles and related commands. Every sentence adds value without unnecessary fluff.

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

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

With no parameters and an output schema, the description still explains the behavioral context thoroughly—what persistent profiles are, how they differ from the ephemeral default, and how they fit into the profile management workflow (create/switch/return). This gives the agent all it needs to decide when to invoke list_profiles.

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

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

The tool has zero parameters, so the input schema fully covers parameters (vacuously). The description adds value by explaining the concept of profiles and the active profile, which gives meaning to the tool's output. No parameter documentation is needed, so a baseline 4 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 'List persistent Chrome profiles and show which one is active,' which is a specific verb+resource+outcome and clearly distinguishes it from siblings like create_profile, use_profile, and delete_profile. It goes beyond the title by specifying the scope (persistent profiles) and the active status.

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 the ephemeral vs persistent profile context and explicitly references create_profile, use_profile, and use_temp_profile as related actions. This gives clear context for when listing profiles would be useful, though it could more explicitly state 'use this before switching profiles' as a direct recommendation.

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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: sessions are stored in ~/.nodriver-mcp/sessions/, are not cleaned up automatically, and accumulate over time. This informs the agent about persistence and potential storage growth beyond what annotations 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 three sentences, each providing distinct useful information: the command's output, how to use it with load_session, and the storage location/cleanup behavior. It is front-loaded with the main action and contains 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?

The tool is simple with no parameters, and an output schema exists, so the description need not explain return values. It sufficiently covers what the agent needs to know: what is listed, how to use it, and the persistence context. The sibling-tool context further helps, but the description stands on its own.

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

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

The tool has no parameters, so the input schema is trivially 100% covered. Baseline for 0 params is 4, and the description does not need to explain parameters. It correctly omits param details and focuses on what the tool returns.

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 the specific verb 'List' with the resource 'saved session files' and details what is shown (name, save time, contents). It clearly distinguishes from sibling tools like save_session and load_session by describing its unique role.

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

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

The description provides clear usage context: it shows the filename to hand to load_session, and notes that sessions accumulate because they are never cleaned up automatically. It does not explicitly mention when not to use it or alternatives, but the purpose is evident from the 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?

Describes non-obvious behaviors: navigation to the saved origin before restoring localStorage, reloading to apply cookies, skipping invalid cookies rather than failing, reporting restore count, and warning that expired tokens may leave the user logged out. This goes well beyond the annotations, which only state flags (readOnly=false, etc.). 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?

Every sentence is informative and earns its place. It opens with the core purpose, then explains the internal procedure, edge-case handling, and a necessary caveat. No fluff or repetition.

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

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

Covers what it does, when to use it, side effects (navigation/reload), failure handling, and what the response reports. With an output schema available, this description is complete for the tool's complexity.

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

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

Input schema covers 100% of parameters with detailed descriptions (filename and restore_pages). The description adds no additional parameter-specific meaning beyond the schema, 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?

States the exact action: 'Restore cookies and localStorage from a saved session file.' It clearly differentiates from sibling tools like set_cookie and save_session by focusing on restoring a previously saved session, and adds the use-case 'at the start of a run to arrive already logged in.'

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

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

Explicitly says when to use ('Use it at the start of a run to arrive already logged in'), and implies a difference from per-cookie/per-localStorage tools. However, it does not explicitly name alternatives or state when not to use it, so it falls 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 important behavioral traits beyond annotations: the master switch semantics, that every action except "list" restarts the browser, and that extensions only persist in a persistent profile. It also honestly states that the tool reports failure on official Chrome rather than pretending to succeed. This adds depth beyond the readOnlyHint/destructiveHint flags.

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 actions, then uses short paragraphs to explain the two mechanisms and platform caveats. Every sentence provides essential context, and no space is wasted. The structure is clear and appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (multiple actions, platform differences, persistence concerns), the description covers all necessary aspects: what it does, when it applies, how actions behave, and limitations. An output schema exists, so return values need not be described. The description is complete enough for an agent to invoke the tool correctly.

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

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

The input schema covers 100% of the parameters with detailed descriptions for both 'action' and 'path'. The description adds some context about the two mechanisms and platform support, but does not materially change the parameter semantics because the schema already explains that 'path' is ignored by most actions. Baseline 3 is appropriate for high schema coverage with some additional context.

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, enable, disable or load Chrome extensions." This clearly distinguishes it from sibling tools, which are mostly browser navigation or interaction tools. The description also explains the two underlying mechanisms, making the 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?

Provides explicit when-to-use and when-not-to-use guidance, e.g., "load" only works on Chromium or Chrome for Testing, and on official Chrome the working path is to install from the Web Store first. This helps the agent select the correct action and understand limitations, which is more than just implying 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?

Beyond annotations, the description discloses that navigating rotates collected logs, preserving the last 3 navigations and making them reachable via include_preserved_* on list tools. It also explains the timing of device emulation and that the tool reuses the current tab. These are important behavioral traits not evident from 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 concise (around 120 words) and well-structured: primary action first, side effects in the second paragraph, and parameter timing combined with return value in the third. Every sentence adds value with no 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?

Given 7 parameters, 2 enums, and a complex navigation side-effect (log rotation), the description covers the essential behavioral context, parameter timing, and return value. It is sufficient for an agent to select and invoke the tool correctly without needing additional documentation.

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% parameter coverage with detailed descriptions. The tool description enhances the meaning of the device parameter by explaining why it matters that emulation occurs before the request is sent, which goes beyond the schema's 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 opens with a specific verb and resource: "Navigate the selected page — load a URL, or go back, forward or reload." It clearly enumerates the tool's actions and distinguishes it from the sibling tool new_page by stating "use new_page to open an additional one."

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 the device parameter versus emulate_device, noting that "calling emulate_device afterwards is too late for that first request." It also states when to prefer new_page over reusing the current tab, offering a clear alternative.

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, openWorldHint=true), the description discloses significant behavioral traits: reuse of the startup tab, selection for subsequent tool calls, device emulation before the first request, and isolated context behavior. This adds substantial 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 compact and front-loaded with the core action. Each sentence contributes valuable behavioral or contextual information without redundancy or filler. It is long enough to cover key nuances but still 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?

Given the tool's complexity, the annotations, and the presence of an output schema, the description covers essential behaviors: tab reuse, selection semantics, emulation timing, and isolated contexts. No critical operational details are missing, and the description is fully sufficient to guide correct invocation.

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

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

The schema already covers all 100% of parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining the timing implications of device emulation, the effect of background on page selection, and how isolated_context names create shared or isolated environments—information not just repeating 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 action: "Open a new browser tab and load a URL," which clearly identifies the tool's purpose and resource. It distinguishes itself from sibling tools like navigate_page by specifying that it creates a new tab rather than navigating the current one.

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 clear context: it explains the first-call behavior in Chrome, the default selection behavior unless background is set, and explicitly references emulation timing compared to emulate_device. It does not explicitly list exclusions or alternatives beyond emulate_device, but the context is sufficient for most use cases.

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 discloses that only one trace can run at a time, the default recording duration (~5s), the output format (raw trace JSON), and the distinction between returning just an event count vs. saving the full trace. This adds significant 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 concise, well-structured, and front-loaded with the core purpose. Each sentence provides essential information—categories, defaults, constraints, and output handling—without any redundant or filler 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?

The description fully covers the tool's behavior given its optional parameters and existing output schema. It addresses the main use cases (self-contained trace vs. manual stop), a key constraint (one trace at a time), and how to handle results, making it complete for a tool of this complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the practical impact of file_path (keeping data vs. just an event count) and clarifying the default behavior of reload and auto_stop, going beyond the schema's field descriptions.

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

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

The description clearly states the tool records a Chrome performance trace of page load or interaction, and it explicitly lists the captured categories. This differentiates it from sibling tools like performance_stop_trace and other page-related actions.

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

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

The description explains the default behavior (reload + auto_stop), when to set auto_stop=false and use performance_stop_trace, and the consequence of omitting file_path. This gives clear when-to-use guidance and references an alternative 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 are minimal (all false hints), so the description carries the burden. It discloses the waiting period, the error case, and the stopping action. This goes beyond what annotations provide, though it doesn't detail output content.

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

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

Three sentences, front-loaded with the main purpose, then usage condition, then behavioral note. No redundancy, every sentence contributes.

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

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

The tool is simple with one optional param and an output schema. The description covers when to use, what it does, and edge cases. The output schema handles return value details, so the description 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?

The single optional parameter file_path has full schema description coverage, explaining how to use it and what happens if omitted. The description adds no extra param info, but baseline 3 is appropriate since the schema is self-sufficient.

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 stops a running performance trace and collects data, referencing the paired start tool. It distinguishes itself from performance_start_trace and clearly communicates the action and resource.

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 specifies when the tool is needed (only with auto_stop=false), when it errors, and the 30-second wait behavior. This gives the agent concrete conditions for use and avoids misuse.

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 indicate readOnlyHint=false and openWorldHint=true, but the description adds critical behavioral context: keys go to the currently focused element, with nothing focused they land on the document body; modifiers are combined with the proper bitmask so chords work. This goes beyond the annotation flags, though it doesn't cover every possible side effect (e.g., navigation or page changes).

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 packed paragraphs: purpose, focus behavior, and alternatives. Every sentence earns its place, no fluff, and the most important facts are front-loaded. Structure is clear and 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?

For a keyboard tool with focus and modifier complexity, the description fully covers usage context, preconditions, and alternative tools. The output schema exists and the parameter schema is rich, so the description need not repeat return formats. No significant gaps remain.

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 with detailed descriptions for both parameters (key examples and include_snapshot's purpose). The description adds a useful detail about modifier bitmasks, which relates to the key parameter, but the schema already carries the full semantic load. Meets the baseline for high schema 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 description opens with 'Send a key press or keyboard shortcut to the page,' which is a specific verb+resource statement. It clearly distinguishes from sibling text-entry tools (fill, type_text) by stating 'this tool is for single keys and shortcuts.' Purpose is unambiguous and differentiated.

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 it ('click or fill the target element first') and provides clear exclusions: 'For entering text use fill (replaces the field) or type_text (appends to it).' This gives actionable guidance on focus requirements and alternative tool selection for text entry.

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 key behavioral traits beyond the annotations: returns a compact listing only, yields no uids and therefore cannot drive clicks, and truncates element text to 200 characters. These details are not captured by readOnlyHint/destructiveHint and add significant value.

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-structured: one sentence on purpose, one on use case, one on limitations, and one on truncation. Every sentence earns its place with no redundancy or fluff.

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

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

For a read-only query tool with a present output schema, the description covers purpose, use cases, limitations, and return format succinctly. It fully equips the agent to decide when to invoke it and what to expect.

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 selector and limit. The description adds no additional parameter-specific semantics, though it does clarify output characteristics. Baseline 3 is appropriate given full schema 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 description opens with a specific verb+resource: 'Find elements by CSS selector; list their tag, text, href, id and class.' It clearly identifies what the tool returns and is distinct from sibling tools like take_snapshot by emphasizing its efficient, focused scope.

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

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

It provides explicit when-to-use guidance: 'The efficient way to pull a repeated structure off a page — search results, product tiles, table rows — without paying for a full snapshot.' It also states when not to use it: 'take a snapshot when you need to interact, or operate on the elements directly via evaluate_script,' naming concrete alternatives.

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

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

The description discloses detailed behavioral traits beyond annotations, enumerating all the emulation overrides that are reset (network throttling, CPU throttling, geolocation, etc.). It also notes the side effect of restoring trusted CDP clicks when touch emulation is turned off, adding valuable context. 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 concise and well-structured. It opens with a clear summary, lists the resets in a compact manner, and closes with usage guidance. Every sentence provides useful 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?

Given the tool's simplicity (no parameters) and the presence of an output schema, the description is fully complete. It covers what the tool does, when to use it, and the precise behavioral scope, including the CDP click note. No gaps remain.

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 doesn't need to explain parameter meaning. The schema coverage is 100% vacuously. The description adds no parameter-specific detail, but the baseline of 4 is appropriate for a no-parameter tool.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Clear every emulation override on the selected page.' It lists the exact types of overrides reset, differentiating it from sibling tools like emulate and emulate_device.

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

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

Explicitly tells when to use the tool: 'Use after emulate or emulate_device to make the page behave like ordinary desktop Chrome again.' It also provides a specific nuance about touch emulation and trusted CDP clicks, giving clear context for 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?

The description discloses that it moves the actual OS window and clarifies that it does not affect device pixel ratio, mobile flag, or touch—those belong to emulation. This adds meaningful context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, with 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 three sentences, each adding distinct value: the action, the use case, and the alternative for viewport emulation. There is no redundancy or unnecessary detail.

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

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

For a simple two-parameter tool with full schema coverage and an output schema, the description fully covers the functionality, its purpose, and its limitations. It is self-contained and complete for an agent to invoke 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% with both width and height clearly described in CSS pixels. The description adds no extra parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Resize the browser window') and the target resource, distinguishing it from viewport emulation tools like emulate and emulate_device. The verb is specific and the scope is unambiguous.

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

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

Explicitly explains when to use this tool (responsive-layout checks requiring accurate screenshots) and provides direct alternatives for viewport-only emulation (emulate's viewport parameter or emulate_device). This gives clear when-to-use and when-not-to-use 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 adds valuable behavioral context beyond the annotations: it renders the entire document, applies the page's print stylesheet, and may differ from the screen layout. This is useful and not contradicted by any annotation. It could have noted potential file overwriting, but given the annotations provided, this is strong.

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 and well-structured: the first sentence states the core action, the second explains key behavioral differences, and the third offers use-case guidance and an alternative. Every sentence earns its place with no 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 moderate-complexity tool with a detailed schema and output schema present, the description covers the key functional aspects (full-document rendering, print stylesheet, archiving use case) and distinguishes the tool from its closest sibling. It is sufficiently complete without unnecessary detail.

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 provides 100% coverage with descriptions for all three parameters, including defaults and effects. The description adds marginal value by relating print_background to the 'print view' behavior, but the schema does the heavy lifting. 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 specifies the tool's function: exporting the current page to a PDF via Chrome's print-to-PDF. It distinguishes itself from the sibling tool take_screenshot by noting that saving as PDF is for archiving, while a pixel-accurate copy would use a screenshot.

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

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

The description explicitly states when to use this tool ('A good way to archive a rendered page as one file') and provides a concrete alternative ('use take_screenshot with full_page instead') for a different use case. This is clear, actionable 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 discloses crucial behavioral traits beyond annotations: storage location ('~/.nodriver-mcp/sessions/'), plain-text credential risk ('treat it as a credential'), origin scoping ('Only the current page's origin contributes localStorage'), and the timestamped filename avoiding overwrites. Annotations only declare readOnlyHint false, destructiveHint false, etc., leaving the description to provide the meaningful safety and data-flow context.

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

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

Four sentences, each earning its place: purpose, use case, storage/security, limitation, and alternative. Front-loaded with the main action and objects, no filler or redundant repetition.

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

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

For a single-parameter tool with an output schema and comprehensive annotations, the description fully covers behavior, security implications, scoping limitations, and the relationship to sibling tools. 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 fully describes the 'name' parameter, including the example 'github-logged-in' and the timestamp append behavior. The description adds no new parameter-specific information, so the baseline of 3 for full schema coverage 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: 'Save cookies, localStorage and open page URLs to a reusable file.' It clearly distinguishes the tool from siblings like load_session (restore) and create_profile (persistent profile) by framing it as the way to keep an interactively obtained login.

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 states when to use: 'This is how you keep a login obtained interactively, so a later run can skip the login flow entirely — restore it with load_session.' It also provides an alternative for a more durable need: 'a persistent profile (create_profile + use_profile) is the sturdier option.' This gives clear when-to-use and when-not-to-use 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=false and openWorldHint=true, so the agent knows this is a state-changing operation. The description adds behavioral context: it triggers lazy-loaded content, may require a follow-up snapshot, and notes that click auto-scrolls. This enriches the understanding of side effects without contradicting 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 concise paragraphs, each earning its place: the first states the core function, the second gives the primary use case and post-action step, the third clarifies when to use alternatives. No filler or repetition.

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

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

For a simple two-parameter tool with full schema coverage, an output schema, and clear annotations, the description covers the essential context: what it does, when to use it, what to do after, and how it relates to sibling tools. This is complete for an agent to correctly invoke it.

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

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

Schema coverage is 100%, with descriptions for both 'amount' and 'direction' that fully explain their format and defaults (e.g., '25 is a quarter screen'). The tool description adds no new parameter semantics beyond what the schema already provides, 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 starts with a specific verb and resource: 'Scroll the page up or down by a percentage of the viewport.' It clearly distinguishes itself from siblings like scroll_to_selector and click by stating its scope (percentage-based scrolling) and its role as the tool for infinite scroll.

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

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

Explicit guidance is given: it is 'The way to trigger lazy-loaded content and infinite scroll,' and the description advises taking a take_snapshot afterwards. It also explicitly excludes alternatives: 'scroll_to_selector is more precise' for known elements, and 'click already scrolls to its target,' so no pre-scroll is needed. This gives clear when-to-use and when-not-to-use 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?

Adds value beyond annotations by explaining the tool 'Reports whether anything matched instead of failing silently' and that it centers the element. Annotations already note non-read-only behavior, and no contradiction exists; the description enriches understanding of the tool's outcome.

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, front-loaded with the primary action, followed by targeted usage guidance and behavioral note. No wasted words; each sentence serves a distinct purpose.

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

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

For a single-parameter tool with an output schema present, the description covers purpose, usage, alternatives, and behavior. It is fully sufficient for an agent 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?

Schema covers 100% of the single parameter with a clear description ('the first match wins'). The tool description restates the first-match behavior but adds little beyond schema; 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?

Description starts with specific verb+resource: 'Scroll the first element matching a CSS selector into view, centered.' It clearly distinguishes from sibling scroll_page by emphasizing precise element-based scrolling, making the tool's 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?

Provides explicit usage context: more precise than scroll_page when target is known, usual preparation for click_at, and unnecessary before click because click scrolls itself. This gives clear when-to-use and when-not-to-use 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 annotations (idempotentHint, etc.), the description discloses that selection is sticky, indices shift as tabs open/close, and if the selected tab is closed the selection is dropped and default applies. Also explains the bring_to_front parameter's effect on backgrounded page animations. 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 paragraphs, 76 words. The first sentence is direct and purposeful. The remaining sentences each add context on behavior and usage. Slightly verbose 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?

For a stateful selection tool, the description covers purpose, default behavior, when to use, index semantics, side effects, and failure mode (tab closed). Output schema exists so return format needn't be described. Well-rounded and 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 covers 100% of parameters with descriptions. The description adds context about indices shifting, but page_id semantics are already in the schema. Bring_to_front is fully described in the schema, so the description adds little beyond what structured data 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 opens with a clear verb+resource: 'Choose which open tab every subsequent tool call acts on.' It distinguishes from sibling tools like list_pages (which lists) and navigate_page (which navigates), and explains the default selection behavior.

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

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

Provides explicit guidance: 'needed when a click opened a tab you now want to drive, or when working across several sites at once.' Also clarifies that without selection, tools act on the most recently opened tab, and that indices come from list_pages — giving a direct reference to the related 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?

Goes well beyond the destructiveHint annotation by disclosing that applying flags restarts Chrome, closes all pages, and drops cookies on ephemeral profiles. Also clarifies the no-argument read-only form and interaction with NODRIVER_ENABLE_* variables, giving a full behavioral picture.

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, each sentence earns its place. The opening states the primary action, the middle explains the read-only form, and the final covers consequences and overrides. No redundancy 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?

Given the output schema exists, parameter descriptions are extensive, and annotations are present, the description covers all necessary context: runtime effect, read-only usage, restart behavior, cookie implications, and environment variable override. Nothing important 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 has 100% coverage with rich per-parameter descriptions (defaults, effects, examples). The tool description itself adds no parameter-specific detail, so a baseline score of 3 is appropriate given the schema handles the semantics.

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

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

The description clearly states the tool changes Chrome's launch flags at runtime and can also show current ones. It specifies the resource (Chrome launch flags) and the verb (change/show), distinguishing it from sibling tools like manage_extensions.

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 clear context on how to use the tool: call with no arguments to read, with arguments to change; explains restart side effects and override of environment variables. Does not explicitly name alternatives or exclusion cases, but the guidance is sufficiently actionable.

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

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

Beyond the annotations, the description discloses that the cookie is a session cookie ('no expiry, gone when the browser closes') and that cookies are browser-wide, not per tab. This is meaningful behavioral context that the annotations do not convey and helps the agent anticipate 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 compact and well-structured: purpose first, then use-case motivation, then key behavioral facts, then the alternative. Every sentence adds distinct value without unnecessary repetition 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 straightforward single-cookie setter, the description covers purpose, applicable use cases, session-cookie behavior, scope (browser-wide), and the appropriate alternative when a full cookie set is needed. An output schema exists, so return-value details are not required. This is complete for the tool's complexity.

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

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

Since the schema has 100% description coverage for all five parameters, the baseline is 3. The description does not add parameter-level details beyond the schema, but it reinforces that a single cookie is being set and gives examples of cookie values, which is mild added context.

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 'Set a single browser cookie,' which is a specific verb+resource statement that clearly identifies the tool's function. It also distinguishes itself from related tools like load_session and get_cookies by framing it as a single-cookie, session-scoped operation.

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

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

The description explicitly states when to use it ('injecting a known session token, consent flag or A/B bucket without walking through a login flow') and provides a direct alternative for a different use case ('To restore a full cookie set including expiry and SameSite, use load_session'). This gives clear decision 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 (idempotentHint=true, destructiveHint=false), the description clarifies that it merges rather than clears, and warns about origin scoping and page startup reads. This adds useful behavioral context. It does not contradict the annotations, though it could be slightly more explicit about overwriting existing keys.

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, each carrying weight: purpose, merge semantics/use case, and critical scoping/reload caveats. No fluff, front-loaded with the main action, and structured for quick skimming.

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

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

For a simple one-parameter tool, the description covers the necessary operational context: origin scoping, prerequisite navigation, and the reload step. The existence of an output schema reduces the need to describe return values. The guidance is complete enough for reliable use.

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 for the single 'items' parameter, including an example and the string-value constraint. The description does not add further parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description opens with a clear verb and resource: 'Write entries into the current page's localStorage.' This immediately distinguishes the tool from its sibling 'get_local_storage' (read vs. write) and from cookie-related tools. It is specific about the action and target.

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 practical guidance: 'Handy for setting feature flags, consent state or auth tokens,' and explains the need to navigate to the site first and reload after setting. It implies when to use the tool but does not explicitly compare it against alternatives like set_cookie or get_local_storage, so it misses the full 'when-not' context.

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