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

Goes well beyond the annotations by documenting timeout semantics, the risk of exceeding the MCP client's request timeout, the fact that a human may take minutes, the post-completion state (session authenticated, you can continue), and the two failure modes (token not issued by request_human_takeover, or already completed). Annotations only say non-readonly/non-idempotent, which conveys far less.

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

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

Front-loads the core action and return semantics, then the polling advice and follow-ups in a logical order. Slightly dense with capitalized emphasis, but nearly every sentence carries operational information; only the resume/notify clause is mildly redundant with the polling advice.

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 the agent needs to call this correctly: how to poll, what `completed` means, what happens on completion, and what causes failure. An output schema exists, so the description is not obligated to detail return structure and doesn't.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real guidance on `timeout` — use a short value (e.g. 4000ms) and poll, rather than the schema's 300000 default — which changes how an agent should set it. `token` is only referenced by provenance (returned by request_human_takeover), matching the schema.

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

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

States a concrete verb+resource: wait for the human to click Done in the takeover page, and defines the success/failure signal (`completed` true/false). It is clearly distinct from siblings like request_human_takeover (which issues the token) and save_browser_state (suggested as a follow-up).

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

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

Explicitly prescribes patterns: run in a background task and poll in a loop with a short timeout (~4000ms) instead of one long blocking call, and explains why (client request timeout, missing the Done signal). It also notes the follow-on action (save_browser_state) and the failure condition for stale/completed tokens.

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 flag destructive/openWorld/non-idempotent, but the description adds substantial context: trusted events grant user activation, popups/new tabs may open, clicks can submit forms or trigger purchases, and out-of-viewport coordinates silently land on nothing. It also notes the returned confirmation and failure modes. This is rich beyond the annotations; only return-format detail is thin (no output schema 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?

Dense and front-loaded, leading with the core action and trusted-event value proposition before usage modes and cautions. A single long paragraph rather than structured bullets, but nearly every sentence carries actionable information.

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

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

With no output schema, the description still states that it returns a confirmation naming what was clicked, and it covers failure modes, side effects, and parameter interplay. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so all five params are documented, but the description adds real meaning: the selector/coordinate precedence, that timeout waits for the selector and scrolls it into view, and that missing/invalid combinations cause failure. This goes beyond the schema's per-field text.

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

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

States a specific verb and resource ('Click in the session's active tab with real CDP mouse input') and immediately distinguishes its behavior from a JS/evaluate click. An agent can tell exactly what this tool does and how it differs from the sibling `evaluate`.

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

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

Explicitly prescribes the two usage modes (selector vs. x/y coordinates), states the precedence rule ('coordinates are used only when there is no selector'), gives an explicit when-not ('Don't use evaluate to click'), and names the failure conditions.

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

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

The annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantive context about exactly what is destroyed: tabs, cookies, storage, console/network logs, and saved .cpuprofile files. It also explains idempotency in operational terms, saying unknown or already-closed sessions succeed and the tool is safe in cleanup code.

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

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

The description is front-loaded with the core action and destruction scope, then moves through usage, alternatives, idempotency, and return behavior. Every sentence carries operational information, and there is no filler.

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

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

For a destructive cleanup tool with rich annotations and a fully documented single parameter, the description supplies what an agent needs: what is deleted, when to call it, when to use alternatives, idempotency safety, and that it returns a confirmation. No output schema is present, but the description notes the return shape.

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

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

Schema description coverage is 100%, and the single parameter already documents that sessionId comes from open_browser_session and that unknown or already-closed ids succeed. The description repeats the idempotency detail but does not add meaningful parameter syntax or format guidance beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: close a browser session. It specifies the scope beyond the name by explaining that all tabs, cookies, storage, logs, and .cpuprofile files are destroyed, and it distinguishes this from close_tab.

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

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

It gives explicit timing guidance: call it when the task is done so the session does not remain open for the reaper. It also names alternatives and their conditions: use close_tab to close one tab and keep the session, and save_browser_state first if the login should outlive the session.

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

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

Beyond the destructiveHint=true annotation, the description discloses the key behavioral consequences: the session survives, index shifting invalidates other indices, the last-tab edge case, and the failure mode for a bad index. This is exactly the context annotations cannot convey for a destructive mutation.

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

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

Front-loaded with the action and its return, and nearly every sentence carries a distinct fact. It is somewhat dense and repeats the 'session stays open' idea in two separate sentences, but no sentence is pure 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 two-parameter destructive tool with no output schema, the description covers return value ('Returns a confirmation'), error behavior, side effects, and the sibling alternative. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new semantics: that indices shift after a close and must be re-derived via list_pages. That is meaning the schema does not express, lifting it above baseline.

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

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

The description opens with a specific verb+resource ('Close the tab at `tabIndex`') and immediately contrasts the scope with `close_browser_session`, so an agent can distinguish the two without reading either schema.

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

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

It gives both a when-to-use-alternative ('To end the whole session, use close_browser_session') and an explicit precondition for reuse ('call list_pages again before using another index'), leaving nothing to inference.

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

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

Goes well beyond the annotations, which only flag destructive=true and idempotent=true. The description adds the non-obvious operational nuance that already-open sessions keep their cookies, and explains the idempotent behavior concretely (missing name returns removed false), which is exactly the context an agent needs before repeating a destructive call.

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 tight sentences, each carrying distinct information: what it does, why to use it, the alternative, and the repeat-safety caveat. The destructive scope is front-loaded before any advisory content.

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

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

For a single-parameter destructive tool with full schema coverage, a rich annotation set, and an output schema, nothing material is left out. The description even pre-explains the removed=false return case, which is more than the output schema alone would guarantee an agent notices.

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

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

Schema coverage is 100% and the schema already documents the allowed character set for `name`, so the description adds little syntax detail. It does supply the semantic pointer that names come from list_browser_states, but that is contextual rather than parameter-level elucidation; 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?

Opens with a specific verb+resource+scope: "Delete a saved browser state by name, permanently." It actively disambiguates from the closest siblings by name (save_browser_state for updates, list_browser_states for discovery), so an agent can pick it without opening any schema.

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

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

States the use case ("forget a login that is stale or no longer wanted"), the explicit alternative for the adjacent intent ("to update a state, call save_browser_state with the same name instead"), and how to find valid inputs (list_browser_states). When-to-use and when-to-use-something-else are both covered.

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?

Despite annotations covering the safety profile, the description adds substantial context beyond them: main-world vs isolated-world execution on stealth sessions, value coercion rules (undefined→null, DOM nodes→{}), promise awaiting, error behavior on thrown exceptions, and the page-mutating nature consistent with destructiveHint=true. 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 dense but front-loaded, moving from core behavior to return semantics, execution-world caveats, alternatives, and failure mode without a wasted sentence.

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

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

Given 3 well-documented parameters, an output schema, and rich annotations, the description still covers the critical agent-facing unknowns: execution world, stealth world isolation, tab targeting, coercion, and error signaling.

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 genuine meaning: it explains that tabIndex runs the code in another tab 'without switching to it' and that the stealth world affects what globals the expression can see, both of which go beyond the schema wording.

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 ('Run JavaScript in a tab') and names the exact return shape (JSON in { result }), which lets an agent distinguish it from siblings like take_snapshot, click, or wait_for immediately.

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 routes the agent away from itself when simpler tools suffice: 'prefer take_snapshot or wait_for when they suffice, and click or type for interaction.' That is an explicit when-not-to-use statement with named 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?

Annotations already declare readOnlyHint and openWorldHint, but the description adds concrete behavioral context beyond them: it changes nothing, it affects the behavior of evaluate and list_console_messages, and a new session starts with stealth off. These are actionable traits not captured by the structured fields.

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

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

Three short clauses, front-loaded with what the tool does and immediately followed by when to use it and the alternative. Every sentence carries distinct information.

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

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

Given the output schema and read-only annotation, the description supplies everything else an agent needs: the default state, the tools whose behavior it affects, and the mutating counterpart. No gaps remain for a one-parameter read tool.

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

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

Schema description coverage is 100% and the sessionId parameter is fully documented, including the error behavior for missing sessions. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (returns whether stealth is on) and resource (for a session), and explicitly distinguishes it from set_stealth, which mutates the setting. An agent can identify its role without opening the schema.

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

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

Gives explicit when-to-use guidance (check before evaluate or list_console_messages), names the mutating alternative (set_stealth), and states the default for a new session. No important routing decision is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: cross-agent visibility, deterministic sort order, null activeUrl for tab-less sessions, and an empty list when nothing is open. It does not mention any cost or limit, but none is evidently needed for a zero-arg read.

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

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

Front-loaded with the verb and scope, then siblings, then edge cases; every sentence carries information. It is dense, packing sort order, cross-agent scope, null semantics and empty-list behavior into a few clauses, but none of it is filler.

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

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

An output schema exists, so return values need no prose, yet the description still clarifies the one ambiguous field (activeUrl null) and the empty-result case. For a zero-param read-only listing tool, an agent has everything needed to call it and interpret the result.

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

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

The tool takes no parameters, which is stated explicitly ('it takes no arguments') and confirmed by an empty schema, so there is no parameter semantics to explain. Baseline for zero parameters applies.

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

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

States a specific verb and resource ('List every open browser session on the shared Chrome') plus scope details (sorted by sessionId, includes sessions opened by other agents). The sibling distinction is explicit: list_pages for tabs, list_browser_states for saved logins, so an agent can route without opening a schema.

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

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

Gives both positive triggers ('recover a lost sessionId or to find sessions left open') and explicit exclusions naming the two alternative tools and what each is for. Nothing about when to choose this tool is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful context: the tool takes no arguments, changes nothing, sorts by name, returns an empty list when nothing is saved, and represents saved logins on disk rather than open sessions. This goes beyond the annotations and clarifies behavior that matters for selection.

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

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

The description is front-loaded with the core purpose, then adds disambiguation and edge-case behavior in a compact form. Every sentence contributes useful selection or invocation information.

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

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

For a simple no-parameter read tool with an output schema and clear annotations, the description is complete. It explains the resource, sibling distinction, usage, sorting, empty-state behavior, and lack of side effects.

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

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

The schema has zero parameters at 100% coverage, so there are no parameter semantics to explain. The description correctly notes that it takes no arguments, which is the only relevant parameter-level detail; the baseline for zero parameters is 4.

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

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

The description states a specific verb and resource: list saved browser states, defined as cookie sets saved by save_browser_state and accepted by load_browser_state/delete_browser_state. It also distinguishes this from list_browser_sessions, so an agent can differentiate it from siblings immediately.

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

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

It explicitly says to use this tool to pick a name to load, and directs the agent to list_browser_sessions for open sessions. That covers the key when-to-use and when-not-to-use case among the 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?

Goes well beyond the readOnlyHint annotation by disclosing non-obvious preconditions and lifecycle behavior: results are empty unless the listener role is running, nothing is captured while stealth is on, and logs are deleted when the session closes. The merge/limit interaction ('limit keeps the newest') is also behavior an agent could easily get wrong.

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

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

Front-loaded with the purpose, then the alternative, then parameter behavior, then preconditions — a sensible ordering. It is dense and the phrase 'oldest first, from the most recent `limit`' takes a beat to parse, but no sentence is filler.

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

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

With an output schema handling return values and annotations covering safety, the description fills exactly the remaining gaps: prerequisites (listener role), known blind spot (stealth), data lifecycle (deleted on close), and scoping. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: without `visit` the messages from every visit are merged and `limit` applies to the newest, and `visit` is sourced from list_visits' `seq`. This is a genuine increment, though it stops short of giving limits or a default reminder.

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

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

States a specific verb and resource ('List console messages') and enumerates exactly which message kinds are included (console.log, warnings, errors, uncaught exceptions). It also explicitly separates itself from list_network_requests, so an agent can distinguish it from the nearest sibling without opening the schema.

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

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

Gives an explicit use case ('Use it to debug page errors') and names the alternative with its own condition ('use list_network_requests for failed requests'). It also explains the visit-vs-no-visit choice, so both usage decisions are resolved in the text.

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

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

Annotations declare readOnlyHint=true, and the description adds context annotations cannot: output is empty unless the listener role is running, logs are deleted when the session closes, and a null status means the request was still in flight. These are operationally decisive facts an agent would otherwise learn only by failing.

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?

Information is front-loaded: purpose, then alternatives, then parameter behavior, then caveats. Every sentence carries weight, though the opening clause ('from the most recent `limit`: method, URL...') packs ordering, paging and return fields into one dense phrase that takes a second read.

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

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

An output schema exists, so return shape needs no explanation, and the description covers the prerequisites (listener role), lifecycle (logs deleted on session close), and the null-status edge case. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: without `visit`, requests from all visits are merged and `limit` keeps the newest. That interaction between the two optional parameters is not spelled out in the schema. It stops short of describing any format specifics for the visit seq beyond pointing at list_visits.

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

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

States a specific verb and resource ('List the network requests the session's pages made') plus ordering ('oldest first') and the fields returned (method, URL, status, redirects, body). It explicitly distinguishes itself from list_console_messages, so an agent can choose without opening either schema.

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

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

Gives concrete when-to-use cases ('check API calls, tracking pixels and failed loads') and names the alternative for the adjacent concern ('use list_console_messages for script errors and logs'). It also states when to pass `visit` versus omitting it, which is the real routing decision for this 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?

Beyond the readOnlyHint annotation, the description explains stable ordering, active-tab marking, index stability, index shifting after a tab close, the empty-list state, and that a subsequent navigate opens a new tab. These details materially affect how an agent should interpret and use the returned list.

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

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

The description is front-loaded with the core action and is dense with useful operational detail. Every sentence contributes either purpose, usage routing, active-tab semantics, or index behavior, without redundant 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 single required parameter, complete schema coverage, existing output schema, and read-only annotations, the description covers the remaining behavioral questions: ordering, active-tab identification, index stability, empty-state behavior, and when to choose this tool over siblings. Nothing essential for correct invocation appears missing.

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

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

The only parameter is sessionId, and the schema already provides a complete description of it, including that it comes from open_browser_session and errors if no open session matches. The description does not add further parameter-level meaning, so the high schema coverage supports a baseline score of 3.

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

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

The description begins with a specific verb and resource: 'List the session's tabs in a stable order.' It also distinguishes this tool from session listing and visit-history listing by explicitly naming list_browser_sessions and list_visits as different resources.

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

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

It gives explicit call conditions: use it before switch_tab, close_tab, or evaluate/profiling with tabIndex to get a current index. It also names alternatives for different needs, directing agents to list_browser_sessions for sessions and list_visits for navigation history.

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 'reads logs and changes nothing' is largely redundant. The description does add real behavioral context the annotations can't: ordering (oldest first), the lifecycle rule that visits are deleted when the session closes, and the empty-unless-listener-running condition. Missing only details like result caps or retention 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?

Four short sentences, front-loaded with what the tool lists and its ordering, then routing to related tools, safety, and preconditions. 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?

A read-only listing tool with one fully-described parameter and an output schema. Ordering, the seq/visit contract, empty-state precondition, and lifecycle are all covered; nothing an agent needs to invoke it 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?

With one param fully documented in the schema, the 3 baseline applies; the description goes beyond it by explaining what a visit's seq means and that the number is what should be passed as `visit` to other tools. It doesn't describe the sessionId parameter itself, but the schema already does.

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 specific resource (session page visits) and scope (oldest first, one top-level navigation per tab, numbered by seq). Explicitly distinguishes itself from list_pages ('for the tabs open now') and names the downstream consumers list_console_messages and list_network_requests.

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

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

Gives explicit use case ('find which page load to inspect') and the alternative to pick instead (list_pages for currently open tabs). Also states the precondition 'Empty unless the listener role is running', which tells the agent when the tool will yield nothing.

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 substantial context beyond the annotations: exact replacement semantics (same name/domain/path overwritten, others kept), the fact that expired logins won't work, and the failure condition when no state exists. This directly explains the destructiveHint=true annotation rather than contradicting it.

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

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

Front-loaded with the core action, then sequencing, then edge cases. Dense but every sentence carries operational information; slightly long for a two-parameter tool but not padded.

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

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

An output schema exists so return values need no explanation, and the description covers sequencing, failure modes, cookie-overwrite behavior, and remediation. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so parameters are already documented; the description still adds value by stating the failure condition for an unknown 'name' and pointing to list_browser_states for valid names, plus confirming sessionId must come from an open session.

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

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

States a specific verb and resource ('Load cookies saved by save_browser_state into this session') and anchors itself in the workflow right after open_browser_session and before navigate, which distinguishes it from siblings like navigate or request_human_takeover.

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

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

Gives explicit sequencing advice, notes that already-open pages need a reload/navigate, names the fallback (request_human_takeover) when cookies fail, and points to list_browser_states for discovery. Both when-to-use and when-not/alternative paths are covered.

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

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

Adds real context beyond the annotations: the move is a trusted CDP input event that fires hover/mouseover/mousemove handlers, out-of-viewport coordinates are silently accepted and hover nothing, and the call returns a confirmation with the position. The non-rejection of out-of-range values is a genuinely useful non-obvious behavior. It does not state error conditions beyond the session lookup (already in schema) or whether the page is scrolled/waited on.

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

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

Front-loaded with the core action and coordinates, then usage, then exclusions and edge-case behavior. Every clause carries information, though the first sentence is dense with parentheticals stacked back to back.

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 3-parameter tool with no output schema, the definition covers action, coordinate semantics, side effects on page handlers, out-of-bounds behavior, exclusions, and the return value shape. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by clarifying the coordinate origin (top-left of the viewport), the unit (CSS pixels), and what happens when coordinates fall outside the viewport. Minor remaining ambiguity: behavior with fractional or negative coordinates is left implicit.

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

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

States a specific verb (move) and resource (the mouse) with precise scope: viewport CSS pixel coordinates in the session's active tab via CDP input. It distinguishes itself from click/scroll siblings by naming them, so an agent can route correctly without opening either schema.

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

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

Gives positive use cases (open hover menus and tooltips before reading or clicking them, add human-like telemetry) and an explicit exclusion with the alternative named: 'Don't use it to click, drag or scroll: use click and scroll.' Both when and when-not are covered with a concrete routing rule.

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

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

With annotations covering read/write and open-world traits, the description adds real behavioral context: auto-opening a tab when none exist, the fact that timeout bounds only the load-event wait (page may still be loading on failure), post-redirect returned url, and net-error failure modes like net::ERR_NAME_NOT_RESOLVED. It does not discuss session-state persistence or auth, but those don't apply here.

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

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

Front-loaded with the core action and completion semantics; every sentence carries distinct information (routing, schemas, timeout scope, redirect behavior, failure modes). It is dense prose without visual structure, which is slightly harder to scan, but nothing is wasted.

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

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

For a 3-parameter navigation tool with an output schema, the description covers the operation, alternatives, parameter constraints, edge cases, and failure modes. Nothing an agent needs to invoke it correctly is missing, and return-shape explanation is a bonus rather than a gap-filler.

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 goes beyond it by enumerating allowed schemes (https, http, data, about) and clarifying that timeout scopes only the load-event wait rather than the whole navigation. sessionId semantics are left to the schema, which handles them adequately.

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

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

States a specific verb and resource ('Load a URL in the session's active tab') plus the completion condition ('return once the page's load event fires'). Immediately contrasts with new_page, so an agent can distinguish it from the sibling that loads a URL in a new tab without opening a schema.

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

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

Explicitly names two alternatives and the condition selecting each: use new_page to preserve the current page, and wait_for afterward when content arrives after the load event. It also covers the edge case where all tabs are closed, leaving no routing ambiguity.

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 annotations (which only declare it is a non-readonly, non-idempotent, open-world, non-destructive mutation) by disclosing the load-event timing semantics, the partial-failure behavior ('the call errors but the new tab still exists and is active'), and the persistence model. The error-still-mutates detail is exactly the kind of trait that prevents an agent from retrying blindly and creating duplicate tabs.

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

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

Front-loads the core action and its activation side effect in the first clause, then layers routing, lifecycle, and error semantics in decreasing order of importance. Every sentence carries distinct information — routing, cleanup, load timing, failure mode, return value — with no repetition of the schema or annotations.

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

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

With only 2 parameters and an output schema present, the description covers everything an agent needs: what is created, that it becomes active, how long it lives, what happens on load failure, and how the returned index relates to list_pages. Nothing material is left to inference.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the about:blank default, making the baseline 3. The description adds real meaning on top: that supplying `url` blocks the call until the load event and how failure is surfaced. It does not restate sessionId semantics, which is fine since the schema covers them.

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

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

States a specific verb and resource ('Open a new tab in the session') plus the side effect that matters most ('make it the active tab'), and immediately explains the downstream consequence for navigate/click/type/screenshot calls. It explicitly names the siblings it is not (navigate, switch_tab), so an agent can route correctly without opening any schema.

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

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

Gives explicit when-to-use versus alternatives: 'Use navigate instead to load a URL in the current tab, and switch_tab to go back to an existing one.' It also names the two cleanup paths (close_tab, close_browser_session) and warns that tabs persist otherwise, covering the resource-leak avoidance case an agent would otherwise miss.

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

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

Annotations only declare the generic create/side-effect profile (readOnly=false, idempotent=false). The description adds substantial context beyond that: cookie/storage isolation between contexts, a blank starting tab, immutability of viewport and useMobileUA for the session's life, lifetime rules (close_browser_session or reaper closing after MAX_IDLE_HOURS default 24), and a concrete failure mode (Chrome unreachable at BROWSER_URL).

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

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

The first clause is the action and return value, the next is the mandatory next step, then escaping constraints, then lifetime, then failure. Every sentence carries a rule an agent must act on; nothing is filler.

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

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

With an output schema present, return values need no explanation, and the description covers creation semantics, isolation, sequencing, lifetime, and error behavior for a 2-optional-parameter tool. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented in structured fields. The description nevertheless adds meaning the schema lacks: that viewport and useMobileUA are fixed for the session's entire life, which affects how an agent decides when to set them.

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

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

States a specific verb ('Open') and resource ('isolated browser session'), immediately follows with what it returns ('return its sessionId') and what it creates (a separate Chrome BrowserContext). An agent can distinguish it from new_page, list_browser_sessions, and close_browser_session without opening any schema.

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

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

Explicit sequencing rules: 'call this first, then pass the id to every other tool', 'Don't open a new session per page: reuse one and use new_page for more tabs', and 'To start logged in, follow with load_browser_state before navigate.' It names the alternatives and the condition that selects each, including a when-not case.

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

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

Adds real behavior beyond the annotations: focus acquisition, that `timeout` is unused without a selector, that Enter can submit a form 'like a real user', and explicit failure modes (unknown key name, selector never matching). The destructiveHint is implicitly supported by the form-submission warning, though it is not stated bluntly as a data-changing side effect.

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

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

Front-loaded with the core action, then modes, then alternatives, then failure behavior — a sensible ordering with no filler. Slightly dense in the middle clause about selector/timeout, but each sentence carries information an agent needs.

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 all four parameters, the two execution paths, the sibling alternatives, the notable side effect (form submission), the return signal ('a confirmation'), and the failure conditions. With no output schema, this is enough for an agent to call it correctly and anticipate outcomes.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by explaining the interaction between `selector` and `timeout` (timeout is dead weight without a selector) and by giving a concrete use pattern ('type into a field then press Enter') that the schema does not convey.

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

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

States a specific verb and mechanism ('Press a key via CDP keyboard input in the session's active tab') and immediately scopes it against siblings with 'Use type for whole strings and click to activate buttons.' An agent can distinguish press_key from type and click without opening any schema.

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

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

Explicitly states the two operating modes: with a selector it waits and focuses first, without one it presses on whatever is focused. It also names alternatives (type, click) and the condition that selects them, leaving nothing to inference.

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

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

Annotations only flag it as non-read, non-idempotent, open-world and non-destructive; the description goes well beyond that by disclosing that it does NOT block, that the returned URL is a bearer credential granting live control of the tab until ttlMinutes expires, that it fails when TAKEOVER_BASE_URL is unconfigured, and that the token must be retained for await_human_takeover.

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

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

Front-loaded with purpose, then usage gating, then operational warnings; every sentence carries actionable content. It is dense and slightly long, with the bearer-credential point and the background-task advice each taking a full clause, but nothing is expendable.

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

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

An output schema exists, so return-value detail is not required, and the description still tells the agent what to do with the returned url and token. Combined with the failure mode, non-blocking behavior and concurrency guidance, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it frames the URL/token lifecycle around ttlMinutes (short-lived because the URL is a credential) and clarifies that it acts on the session's active page rather than any page. It does not restate the 1-60 cap or default, leaving that to the schema.

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

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

States a specific verb and resource: hand the session's active page to a human to log in themselves. It draws a sharp line against sibling tools by naming the parenthetical reason (passwords/passkeys the agent must not see), so it is unmistakable versus click/type/evaluate or load_browser_state.

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

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

Gives both when-to-use ('only when a login needs a person') and an alternative to try first ('for a site you've logged into before, try load_browser_state first'). It also sequences the follow-up tool and prescribes how to run it (await_human_takeover in a background subagent/job, not the main loop).

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 (destructive/idempotent/openWorld=false), it discloses overwrite-on-existing-name semantics, that only cookies are captured (not localStorage) so some sites won't resume, that states are stored as plaintext credentials, and that invalid names fail — all material facts an agent cannot get from the schema or 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 compact sentences, front-loaded with the action and purpose, then prerequisites, then caveats. Every sentence carries distinct operational information with no repetition of the schema.

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

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

An output schema exists, so return values need not be explained. For a two-parameter state-mutation tool, everything an agent needs — when to call, naming, overwrite risk, coverage limitation, and credential exposure — is present.

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

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

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining that 'name' acts as a key whose reuse replaces prior state, and restates the allowed character set — though it does not elaborate on sessionId beyond what the schema already says.

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

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

States a specific verb+resource (save session cookies under a name) plus the payoff (resume without logging in), and explicitly names the complementary sibling load_browser_state so the agent can tell it apart from list_browser_states/delete_browser_state.

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

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

Gives concrete triggering conditions ('after a successful login', 'once await_human_takeover completes') and a naming rule ('use a distinct name per site or account'). It also names the follow-up tool that consumes the artifact, leaving nothing to inference.

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

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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), and the description adds the timing behavior that annotations cannot express: it returns immediately without waiting for content to load. It does not discuss rate limits or failure modes, but the key operational caveat is present.

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

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

Front-loaded with the core mechanism, then the targeting rule, then units, then use cases, then the exclusion. Every sentence carries distinct information and none repeats the schema verbatim.

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

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

For a five-parameter interaction tool with no output schema, the description covers the mechanism, targeting, units, timing behavior, follow-up requirement, and anti-pattern. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is already 100%, so the schema documents defaults and units. The description still adds real semantics beyond the schema: the delta units and sign direction, and crucially that x/y select which scrollable panel receives the wheel event rather than being arbitrary coordinates.

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

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

States a specific verb (scroll) plus the mechanism (real mouse-wheel event at a viewport position), and explains the targeting rule that the element under (x,y) scrolls rather than the page. This is clearly distinguishable from the sibling click and move_mouse 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?

Explicitly names both when to use it (revealing lazy-loaded content, generating human-like behavioral signals) and when not to ('Don't use it just to reach an element before clicking'), and names the alternative behavior that replaces it (click scrolls its target into view). It also prescribes the follow-up pattern with wait_for.

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 past the annotations by naming the concrete costs of each mode: no console capture and an isolated-world `evaluate` that cannot read window globals while on; restoration of console capture and main-world access while off. It also explains why the tradeoff exists (Runtime.enable is an automation tell Cloudflare detects), which annotations cannot 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?

Front-loaded with a one-line purpose, then the true-case, then the false-case, then the typical flow. Dense but every sentence carries unique operational information; nothing is repeated from the schema.

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

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

Output schema exists, so return values need no explanation, and the mode tradeoffs and error condition (session must be open) are covered. Minor gaps: it never says whether stealth persists across navigations or how to verify current state (get_stealth), leaving the agent to guess on state inspection.

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 substantial meaning beyond "true turns stealth on": it explains the downstream consequences of each boolean value on console capture and `evaluate` scope. That is genuine semantics the schema does not carry.

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?

"Toggle stealth for a session" gives a specific verb (toggle) and resource (session stealth), and the body spells out exactly what the tool changes: the CDP Runtime domain. The mechanics make it unmistakable from the read-only get_stealth sibling, even though that name is never mentioned.

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

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

Gives an explicit recipe ("set_stealth(true) → navigate → set_stealth(false) → evaluate") plus an explicit when-not ("Leave it off for sites without bot detection"). An agent knows both the sequence and the exclusion without inference.

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

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

Annotations only declare the mutation/idempotency profile; the description adds the operationally important facts an agent can't get from them: profiling keeps running until stop_profiling, calling again fails while a recording is active and the existing one continues, and higher sampling costs overhead and a larger profile. It also mentions the return value (a confirmation).

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

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

Front-loaded with the action and default, then workflow, then tuning, then failure mode. Dense but nearly every clause carries information; the sampling discussion is the one place it could be trimmed slightly.

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, non-idempotent tool with no output schema, the description covers the full lifecycle (start → reproduce → stop), the failure mode, and the fact that it returns a confirmation. An agent has everything needed to call it correctly and clean up.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds real meaning by explaining when to deviate from the 1000µs default and what the tradeoff is, plus that tabIndex defaults to the active tab. It adds rationale rather than restating types, though it doesn't tie advice to each parameter individually.

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

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

States a specific verb and resource ('Start the V8 CPU profiler on a tab') with scope clarified (active tab by default, or tabIndex). Immediately distinguishes itself from list_network_requests by naming the excluded concern (network slowness) and points at stop_profiling as its pair.

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

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

Gives an explicit workflow (start, reproduce, then stop_profiling on the same tab), an explicit when-not (network slowness → list_network_requests), and concrete tuning advice for samplingIntervalUs. Alternatives and exclusions are both named rather than inferred.

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 annotations by explaining that a .cpuprofile is saved, where it lives, how to open it, what analysis is returned, and that hung page JS may be terminated after terminateAfterMs. It also discloses lifecycle behavior: the file is deleted with the session by close_browser_session, which is important given the destructive annotation.

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

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

The description is front-loaded with the core action and the rest is dense but mostly useful. It is longer than ideal as a single paragraph, but every sentence carries operational information for a complex tool.

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

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

For a complex profiling tool with an output schema, annotations, and five parameters, the description is complete enough to call correctly. It covers prerequisites, side effects, output location, result contents, failure conditions, parameter interactions, and session-bound file lifecycle.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful semantic detail beyond the schema: tabIndex must match start_profiling, top caps each ranked list, terminateAfterMs of 0 never terminates, and timeout should be a few seconds above terminateAfterMs.

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

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

States a specific verb and resource: stop the CPU profiler started by start_profiling, and describes the saved .cpuprofile plus the returned culprit analysis. It is clearly distinguishable from sibling tools like start_profiling and close_browser_session.

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

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

Explicitly says to use it after start_profiling, requires passing the same tabIndex, and fails if start_profiling was not called on that tab. It also gives practical guidance for terminateAfterMs, top, and timeout, including when to raise `top` and how to set `timeout` relative to `terminateAfterMs`.

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 explains that switching affects later navigate/evaluate/screenshot/click/type calls, brings the tab to the front in Chrome, and moves the human-takeover live view with it. It also discloses that indices shift when tabs close and that failure occurs if no tab exists at that index.

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 primary action and consequence, then adds alternatives, index volatility, and failure behavior in tight sentences. Every sentence earns its place.

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

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

Given the annotations, full schema coverage, and available output schema, the description supplies the remaining behavior an agent needs: targeting effects, tab-to-front behavior, index volatility, alternatives, and failure condition. Nothing important for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantic context about tabIndex: it comes from list_pages, shifts when a tab closes, and should be refreshed if uncertain. It also explains an alternative use of tabIndex with evaluate/profiling tools without switching.

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 and resource: it makes the tab at tabIndex the active tab. It also distinguishes this from new_page and from acting on another tab via evaluate/profiling without switching.

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

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

It explicitly says to use new_page to open a tab and to pass tabIndex directly to evaluate or profiling tools when switching is unnecessary. It also gives practical guidance to re-list pages if indices may have shifted and states the failure condition.

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

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

The statement 'It reads the page without changing it' aligns with readOnlyHint=true and reinforces it for a screenshot operation an agent might suspect of side effects. It adds a genuinely useful warning that fullPage 'can make a very large image on long pages' and discloses the return format (image plus byte-size caption). Minor gap: no mention of size limits, truncation, or failure modes for pages that never finish loading.

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

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

Front-loads the core action, then routing to alternatives, then the one behavioral caveat and the return format. Every clause carries decision-relevant information; no restatement of the tool name 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?

With no output schema, the description still explains the return value (image plus a caption with byte size) and covers safety and cost tradeoffs for the only optional parameter. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a consequence not present in the schema: fullPage captures the whole scrollable page and may produce a very large image on long pages. That cost signal helps an agent decide whether to pass the flag, going beyond the schema's neutral 'Default false.'

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

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

States a specific verb and resource ('Capture a PNG of the session's active tab') and the return shape ('return it as an image'), which is distinct from take_snapshot (text structure) and evaluate (specific values). An agent can distinguish it from every sibling without opening a schema.

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

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

Explicitly names when to use it ('when visual layout, styling or images matter') and names the two alternatives with the conditions that select them: take_snapshot for a cheaper text view, evaluate for specific values. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description reinforces it ('reads the page without changing it') and adds useful context the annotations don't carry: it returns the whole tree unfiltered, so large pages produce long output. No mention of any rate limits or truncation behavior beyond output length, which keeps it short of a 5.

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

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

Front-loads what is returned before the routing advice and the output-size caveat. Dense but every clause earns its place — the sibling comparisons and the long-output warning both change agent behavior.

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

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

For a one-parameter read tool with no output schema, the description supplies the return shape (indented text, role + name, nested by structure) and the output-size caveat, plus the decision boundary against two siblings. Nothing an agent needs to call it correctly is missing.

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

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

Only one parameter (sessionId) with 100% schema description coverage that already explains it comes from open_browser_session and errors if missing. The description adds no parameter-level detail, which is acceptable given the schema does the work; baseline 3 applies.

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

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

States a specific verb and resource ('Return the accessibility tree of the session's active tab as indented text') and enumerates the content: roles, names, links, buttons, headings, form fields, labels, current values. This makes it immediately distinguishable from take_screenshot and evaluate.

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

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

Explicitly routes between siblings: use this to find what's on the page and what to click or type into, 'far more cheaply than take_screenshot'; use take_screenshot when visual layout matters; use evaluate for data not shown as text. Both the when and the when-not are named with 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?

Goes well beyond the annotations (destructive/openWorld/non-idempotent) by disclosing the wait-then-click-to-focus sequence, real key event dispatch so page handlers fire, and the failure mode of a non-matching selector. The most valuable disclosure is the silent no-op on non-editable targets — success reported but nothing changed — which no annotation conveys.

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

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

Front-loaded with the core action and mechanism, then usage routing and caveats. It is a single dense paragraph with no filler sentences, though the caveat about non-editable elements could be its own sentence for scanability.

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

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

There is no output schema, and the description compensates by stating the return value (number of characters typed) and the failure condition. For a 6-parameter mutation tool, the description covers what an agent needs to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds behavioral meaning the schema does not: timeout governs both waiting for the element and the failure condition, clear vs append semantics, and delay exists for speed-sensitive pages. It stops short of adding format details for selector/sessionId, 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?

States a specific verb and target (type text into the first element matching a CSS selector in the active tab) and explains the mechanism (focus click + real key events). It is clearly distinguished from press_key, which it names as the tool for single keys and Enter/Tab.

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 routing: use press_key afterwards for Enter or Tab, press_key alone for single keys, and target an input/textarea/contenteditable rather than a button. The clear-vs-append choice and the delay option are both framed by when you'd want them.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'reads the page without changing it' plus concrete runtime traits: 100ms polling, timeout-based failure, and which value is returned. It does not cover whether the wait can be cancelled or how long the default timeout is (the schema covers the default), so it is strong but not exhaustive.

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 what and the scope lead, usage guidance and precedence follow, and edge cases (case sensitivity, hidden text, timeout failure) close it out. Every sentence adds information; nothing is repetitive of the name or schema.

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

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

For a 4-parameter, single-required-argument wait tool with no output schema, the description covers invocation, precedence, matching semantics, failure mode, and the return value. An agent has everything needed to call it correctly on the first attempt.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by documenting the precedence rule when both `selector` and `text` are given, that `text` matches case-sensitively against document.body.innerText, and that CSS-hidden text does not count. These are semantics not visible in the schema 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?

States a specific verb (wait) with two precise resources (CSS selector match / text appearing in visible page text), scoped to the session's active tab and a concrete polling interval. An agent can distinguish it from take_snapshot or evaluate without opening any schema.

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

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

Explicitly says to use it 'after navigate, click or scroll when content loads asynchronously, instead of sleeping,' naming both the triggering context and the alternative behavior to avoid. Also states the failure condition when neither argument is supplied, which routes the agent away from calling it blindly.

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