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

The description adds substantial behavior beyond annotations: ordered execution, stop-on-first-error with action identification, partial effects remaining, no retries, auto-wait/scroll behavior for element targets, coordinate/wheel non-waiting behavior, button release on cancelled/timed-out clicks, and load-wait scope. These details are consistent with destructiveHint=true and give the agent a precise operational picture.

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

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

The description is front-loaded with the core purpose and return behavior, then adds operational constraints in compact sentences. Every sentence carries useful information, with no repetition or filler.

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

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

For a complex, destructive, open-world tool, the description covers execution order, error behavior, partial effects, retry policy, waiting semantics, and return format. The schema supplies parameter details and session prerequisites, so the description is complete enough for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents parameters thoroughly. The description still adds actionable semantics by clarifying that element mouse targets auto-wait and scroll into view while coordinate and wheel actions do not wait, and that load waits observe the current document rather than future navigation.

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: run ordered browser actions covering mouse, field, key, dialog, and wait categories. It also distinguishes the output profile by returning plain text without a snapshot, making the tool's role clear relative to screenshot/extract/fetch siblings.

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

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

The description implies usage through its list of interactive action types, but it does not explicitly say when to choose this tool over browser_evaluate, browser_extract, browser_fetch, or other siblings. There are no named alternatives or exclusions, so routing is left partly 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 destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds two pieces of genuine context the agent could not infer: script effects are not undone on failure, and cancellation may not stop the script. That is exactly the operational caveat a caller needs before invoking an irreversible page 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?

Four short sentences, front-loaded with the core action, then return-value normalization, then two failure caveats. No filler; the only mild cost is that 'without a snapshot' is left unexpanded.

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 explaining the return shape (JSON text, null/undefined coerced to null). Combined with the failure and cancellation caveats, the agent has enough to invoke it safely; only error-signaling specifics are absent.

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

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

Schema coverage is 100%, so each parameter (including isolated_context and arg) is already documented in the schema; the description adds no parameter-level guidance such as when to disable isolated_context or how expression vs arg interact. Baseline 3 applies when the schema carries the load.

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

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

States a specific verb+resource ('Run JavaScript on the current page') plus scope details: awaits promises and returns JSON text without a snapshot, which implicitly distinguishes it from browser_screenshot and browser_extract. It never names a sibling, so differentiation is inferential rather than explicit.

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

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

'without a snapshot' hints that this is the no-screenshot path, but there is no explicit statement of when to choose browser_evaluate over browser_extract, browser_actions, or browser_fetch, nor any prerequisite sequencing beyond the session_id note in the schema.

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

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

Beyond the readOnly/openWorld annotations, the description discloses that extraction does not navigate and that snapshot search preserves refs, ancestor paths, and nearby context. It does not cover error behavior or permission requirements, but it adds useful behavioral detail for a read-only extraction tool.

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

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

The description is two tightly written sentences with no filler. It front-loads the action and scope, then adds the most relevant output 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?

Given the fully described schema and read-only/openWorld annotations, the description is largely complete: it covers formats, non-navigation, and snapshot search context. It does not fully explain return shapes for every format, which is a minor gap because no output schema exists.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description adds some useful context about snapshot search output, but it does not add parameter-level meaning beyond what the schema already provides for target, depth, boxes, session_id, and main_content_only.

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

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

The description states a specific verb and resource: read the current page or one element as snapshot, HTML, Markdown, or text. The phrase 'without navigating' directly distinguishes it from navigation/fetch siblings, so 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?

It gives clear usage context by specifying reading the current page or a single element without navigating. It does not explicitly name alternatives such as browser_fetch or browser_evaluate, so it stops short of full when/when-not routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network reach are covered structurally. The description adds two useful traits — the session is "stealthy" and options do not persist across calls — but says nothing about failure behavior for the 17 options (timeout, cloudflare solving, blocked domains) or what happens when the session is stale.

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

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

Two short sentences, front-loaded with the action and with zero filler. The brevity is efficient; the only cost is that the second sentence is doing very little work for a tool with 17 parameters.

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

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

The output schema covers return values and annotations cover read-only/open-world, so those burdens are lifted. Still, for a 17-parameter tool with 2 required fields, the description should state the session-lifecycle constraint and the distinction from browser_fetch_once; "options apply only to this request" only partly covers that.

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

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

Schema description coverage is 100%, so every parameter including wait, network_idle, pierce_shadow and extraction_type is already documented. The description adds no parameter meaning beyond "options apply only to this request", so the baseline 3 applies.

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

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

States a specific verb and resource ("Fetch a URL") and scopes it to an existing browser session, which separates it from browser_open. However it never names browser_fetch_once or browser_extract, so the sibling with the near-identical name is not disambiguated from the text alone.

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?

"In an open stealthy browser session" implies a prerequisite (session_id from browser_open, as the schema notes) and "Options apply only to this request" hints at per-call vs persistent state. There is no explicit when-to-use/when-not guidance against browser_fetch_once, browser_extract, or make_request.

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=true, so safety and open-world nature are covered. The description adds genuinely useful context by naming stealth and JS rendering, but omits the tradeoffs an agent cares about here — whether a session persists, what gets destroyed, and why one would choose this over browser_fetch.

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

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

A single front-loaded sentence with no filler. It is efficient, though the leanness borders on under-specification given the tool's 27-parameter complexity.

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

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

An output schema and rich annotations reduce what the description must carry, but with 27 parameters and 16 sibling browser/session tools, the description should at least clarify one-shot versus session semantics. It leaves that ambiguity unresolved.

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% across 27 parameters, so the schema carries the full burden of explaining url, wait, timeout, extraction_type, cookies, and stealth flags. The description adds nothing beyond what the schema documents, which is the expected baseline when coverage is this high.

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 (fetch a page) plus the distinguishing mechanism (stealth browser, JavaScript rendering). However, it never contrasts with sibling tools like browser_fetch, browser_open, or make_request, so an agent must infer where it fits.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives. The 'once' in the name implies one-shot versus session-based fetching, but the description never confirms or explains this relative to browser_open or open_request_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?

Annotations only flag destructiveHint=true; the description adds the crucial scope of that destruction (which stores are overwritten), a non-obvious carve-out (sessionStorage and open tabs untouched), and the follow-up needed for the restoration to take effect. That is exactly the kind of detail structured fields 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?

Two sentences, zero filler. The primary effect is front-loaded and the caveats/follow-up immediately follow it.

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 mutation tool with rich annotations and no output schema, the description covers what changes, what doesn't, and what the agent must do next. What remains unstated is behavior on error or a missing/invalid state file, which is a modest gap.

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

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

Schema coverage is 100%, with path and session_id fully documented in the schema. The description contributes only one extra semantic detail, the file being Playwright-compatible, which is minor additional meaning; the schema does the heavy lifting as expected.

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 ('Replace') plus the exact resources affected (cookies, local storage, IndexedDB) and the source format (Playwright-compatible JSON file). This is clearly the inverse of browser_save_state, so an agent can distinguish the pair from the text alone.

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?

'Fetch or reload pages to use the restored login' tells the agent what must happen after the call, and 'Leaves sessionStorage and open tabs unchanged' defines the boundaries of what this call restores. It stops short of explicitly naming browser_save_state as the counterpart or stating when not to use this, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that retrieval does not resend the request and that 'availability notes' accompany the data, which is modest but real context beyond the annotations; it does not explain failure behavior when a part was not captured.

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

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

A single front-loaded sentence with no filler; the non-resend guarantee appears early. The phrasing 'complete saved request part' is slightly dense but every clause carries information.

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

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

An output schema exists, so return structure needn't be explained, and the enum plus request_id provenance cover the parameters. The main residual gap is what happens when a requested part wasn't captured, only loosely covered by 'availability notes'.

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 'part' enum is documented including the note that incomplete headers are marked, plus request_id pointing back to browser_network_requests. The description adds nothing about parameters beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Read') and resource ('a complete saved request part'), and the phrase 'without resending it' implicitly distinguishes it from the fetch/make_request siblings. It stops short of naming browser_network_requests as the companion list tool, so the differentiation is inferred rather than explicit.

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

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

'Without resending it' hints that this is the right choice when you already have a captured request and don't want to re-issue traffic, but there is no explicit statement of when to use this versus browser_network_requests or browser_fetch. Usage is implied, not spelled out.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral fact not in any structured field: recording begins when the browser session opens, so requests before that are not captured. It stops short of describing filtering defaults (static assets excluded) or the cursor mechanics.

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

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

Two short sentences, zero waste, with the core scope ('completed requests across page changes') front-loaded before the lifecycle caveat.

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 and the parameter schema is fully documented, so the return shape and argument semantics need not be restated. The description covers scope and the recording-start caveat; only the static-vs-API default filtering could be surfaced earlier, but the schema handles it.

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

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

Schema description coverage is 100%, with limit, after_id, url_pattern, and include_static all documented inline, including the next_cursor hand-off. The description only echoes the existence of IDs and pagination, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('List completed requests') plus scope ('across page changes') and mentions IDs and pagination. It reads clearly enough to separate it from the singular browser_network_request, though it never names that sibling explicitly.

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

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

Usage is implied rather than stated: 'across page changes' hints this is the paged-list counterpart to fetching a single request, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of browser_network_request or the fetch tools as alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds the meaningful traits 'stealthy' and 'reusable', but says nothing about session lifetime, cleanup requirements (close_session), or resource persistence, leaving important behavioral context unstated.

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

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

Two short sentences, front-loaded with the action and resource, with zero filler. The downstream-tool hint is placed immediately after the core purpose.

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

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

Output schema exists, so return values need not be described. However, for a 14-parameter session opener, the description omits how sessions are reused across calls, whether they must be closed, and what happens if a session_id already exists — leaving the lifecycle under-specified.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds one genuinely useful routing signal: per-request options belong on browser_fetch, clarifying the division of labor between session creation and request execution beyond what the schema alone conveys.

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 reusable stealthy browser session — and names a downstream sibling (browser_fetch). It does not distinguish itself from other session-creating siblings such as open_request_session or browser_fetch_once, so differentiation is incomplete.

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

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

The line 'Pass per-request options to browser_fetch' implies the session is a container for later fetch calls, but it never says when to choose this over open_request_session or browser_fetch_once. Usage is inferable but not explicitly guided.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so safety is covered structurally. The description earns credit for enumerating exactly which storage areas are captured and that sessionStorage is deliberately dropped — a real behavioral constraint beyond the annotations. It does not restate the overwrite behavior, which lives in the path schema.

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

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

Two short sentences, front-loaded with the contents and format, with the exclusion clause placed where it reads as a qualifier. No filler whatsoever.

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 write tool with full schema coverage and destructive annotations, the description supplies the one thing the schema cannot: what state is and isn't captured. The only minor omission is the round-trip relationship to browser_load_state, which an agent restoring state would want stated.

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 path parameter already documents relative-to-working-directory, overwrite, and parent-must-exist semantics, plus session_id ties back to browser_open. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (Save) and a precisely enumerated resource (cookies, local storage, IndexedDB) plus the output format (Playwright-compatible JSON). The explicit exclusion of sessionStorage further sharpens scope. It does not, however, name its inverse sibling browser_load_state, so the pairing must be inferred from the shared 'state' naming.

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

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

The description says what is captured but never when to use this instead of alternatives; the obvious pairing with browser_load_state for persist/restore workflows is left unstated. No preconditions (an open session, a writable host path) are mentioned in the description itself.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description still adds real behavior: no navigation occurs, element capture waits and scrolls into view, and the return includes the image plus the current URL. It omits cost/size implications and timeout behavior, keeping it below a 5.

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

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

Two tight sentences, front-loaded with the core action and the 'no navigation' constraint, then the alternative tool. Nothing is redundant, though the second sentence's phrasing is slightly clipped.

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

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

No output schema exists, and the description compensates by stating what is returned (the image and current URL). Combined with annotations and full schema coverage, an agent has enough to call it correctly; missing pieces like full_page behavior and timeout effects are minor and schema-documented.

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

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

Schema coverage is 100% and each parameter (ref, selector, full_page, quality, image_type, timeout) is documented in-schema, so the baseline of 3 applies. The description's only additional signal is that capture targets either the page or 'one element', which is already inferable from 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 ('Capture the current page or one element') and adds the key constraint 'without navigating', which separates it from navigation-capable siblings like browser_open/browser_fetch. It does not explicitly contrast with browser_extract or browser_evaluate, so sibling differentiation is partial.

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?

One usage pointer is given ('Use browser_actions for other waits before capture'), which is genuinely useful. However there is no guidance on when to prefer screenshots over browser_extract/browser_evaluate, nor on when not to use it (e.g. session not yet fetched, non-visual data extraction).

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

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

Annotations already declare destructiveHint=false, readOnlyHint=false, and openWorldHint=true, so safety framing is covered. The description adds that resources are freed, which hints at resource cleanup, but omits idempotency (what happens on a second close), the effect on in-flight requests, and behavior for an invalid session_id — all material for a lifecycle-mutating 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?

A single front-loaded sentence with zero filler. It is efficient, though its brevity reflects under-specification rather than disciplined compression.

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. However, for a state-changing session-termination tool with annotations only carrying hint flags, the description should at least cover idempotency and error conditions to be complete; it covers neither.

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 exists and the schema documents it at 100% coverage ('Session ID to close.'). The description adds no syntax, format, or origin information for session_id, so baseline 3 applies.

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

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

States a specific verb and resource ('Close a session') plus a secondary effect ('free its resources'). It is distinguishable from siblings like open_request_session and list_sessions, but it never names which session types it applies to, so the boundary with browser sessions vs. request sessions is left implicit.

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

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

No guidance on when to close a session versus leaving it to expire, no prerequisites (e.g., that the session_id must come from open_request_session), and no mention of alternatives such as list_sessions for verifying what exists. The agent must infer the entire lifecycle context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results include status and effective settings, which hints at response content, but says nothing about whether the list is scoped to the current connection or global, or how large it can get.

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

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

A single front-loaded sentence with no filler. It is efficient, though so terse that the key ambiguity about what a 'session' is here goes unaddressed.

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

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

With no parameters and an output schema present, the description needn't explain return values. But given a sibling set dense with both request-session and browser-session tools, the omission of which session domain this lists is a meaningful gap in an otherwise minimal tool.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering inputs are needed, matching the empty 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 (list) and resource (registered sessions) plus the fields returned (status, effective settings). It does not, however, distinguish this from session-adjacent siblings like open_request_session or close_session, so an agent can't tell from the description alone whether these are request sessions, browser sessions, or both.

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

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

There is no guidance on when to call this versus the many sibling session tools, no prerequisites, and no stated outcome for the agent to use in routing decisions. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external reach are covered. The description adds the meaningful behavioral note that no JavaScript executes and that it targets low-to-mid protection sites, but it is silent on the significant behaviors exposed by the schema (retries, impersonation conflicts, redirect safety) that an agent should understand before calling.

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

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

Two short, front-loaded sentences with zero filler and the key differentiator placed early. It is efficiently written, though the brevity borders on under-specification for a 22-parameter 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?

With an output schema present, return values need no explanation, but for a 22-parameter tool with impersonation, retries, proxy, and redirect-safety behaviors, the description omits routing guidance versus the many sibling fetch/session tools and any note on limits or typical failure modes.

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

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

Schema description coverage is 100%, so all 22 parameters are self-documented with defaults, enums, and semantics (e.g. follow_redirects safe mode, impersonate list randomization). The description adds no parameter-level meaning, so baseline 3 applies.

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

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

States a specific verb and resource ("Make an HTTP request") and adds a differentiator against the browser siblings by noting it runs "without JavaScript." An agent can tell this is the non-browser fetch path, though it doesn't name which specific sibling to prefer.

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?

"Suitable for low-to-mid protection" implies a scope boundary and hints that heavier protection needs another tool, but it never names the alternative (browser_fetch, browser_fetch_once, session_make_request) nor states explicit when-not conditions.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true and destructiveHint=false. The description adds genuine value by disclosing persistence semantics (cookies, connections, request settings are retained), but says nothing about session lifetime, resource cleanup via close_session, or whether sessions expire.

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

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

A single front-loaded sentence with no filler; the purpose and the key persistence benefit both land immediately.

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

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

With an output schema present and all parameters documented, the description only needs to cover intent and lifecycle. Intent is covered; the missing piece is that this creates stateful server-side resources that should be released with close_session.

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

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

Schema description coverage is 100%, so proxy, session_id, and impersonate are already fully documented including defaults and the random-hex fallback. The description adds no parameter-level meaning 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 and resource ("Open a reusable HTTP session") and names the sibling it feeds (session_make_request), so the agent can separate it from make_request and browser_open. It stops short of explicitly contrasting with browser_open, which also opens a session-like resource.

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

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

The phrase "for session_make_request" implies the intended pairing, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., use make_request for one-off calls, browser_open for JS-rendered pages). Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network reach are covered. The description adds real context by listing the session state it inherits (cookies, connections, impersonation, proxy) and that "Options apply to this request" (per-call overrides of session defaults). It omits two loaded behaviors an agent needs: whether cookies/state from the response are written back into the session, and that a POST/PUT/DELETE is a genuine external mutation despite readOnlyHint.

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

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

Two short sentences with no filler, front-loaded with the action and the state it consumes. It is not padded, but the second sentence is vague enough that its brevity shades toward under-specification rather than efficiency.

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 and annotations are present, and the schema documents all 20 parameters, so the description needn't restate them. Still, for a tool this behaviorally rich (redirect safety modes, browser impersonation, content extraction, session state carry-over), the description leaves the session/mutation semantics and sibling routing unexplained.

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

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

Schema description coverage is 100% across 20 parameters, so the schema already explains url, method, data/json, retries, follow_redirects and the rest. The description contributes only the blanket claim that options apply per-request, adding no semantics for any specific parameter. Baseline 3 is appropriate when the schema carries the full burden.

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

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

States a specific verb and resource ("Make an HTTP request") and adds the distinguishing trait that it draws on the session's cookies, connection pool, impersonation, and proxy. That implicitly separates it from the stateless `make_request` sibling, but the sibling is never named and an agent must infer the difference.

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

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

Usage is only implied: the phrase "using the session's cookies" hints this is the tool for requests that must stay within an existing session, and the schema's session_id points at `open_request_session`. However, there is no explicit when-to-use / when-not-to-use guidance against `make_request` or the `browser_fetch*` siblings, and no statement that a session must be opened first.

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