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

Annotations already establish a safe read (readOnlyHint=true, destructiveHint=false), and the description adds substantially beyond them: the call is free, consumes no concurrency slot, per-request credit costs, renewal timing, and the meaning of specific error codes with pointers to the response fields they map to.

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?

Purpose is front-loaded in the first sentence, followed by usage triggers then error-code details. It is information-dense and slightly long, but nearly every clause (costs, slot behavior, error meanings) is callable, non-redundant context.

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

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

With no output schema, the description carries the return-value burden and does name key fields (period_ends_at, api_key.caps). Given a zero-parameter, annotation-covered read tool, 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It adds no param-level detail, which is appropriate here.

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

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

States a specific verb and resource: 'Read the current plan's credit allowance and how much of it is spent.' No sibling tool covers account billing/credit state, so the agent can identify this unambiguously.

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

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

Explicitly names the trigger conditions ('before a large batch, or after a 402 / AUTH004') and disambiguates error semantics across AUTH004, AUTH006 and AUTH014, telling the agent when this tool applies versus when the error means something else.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the agent knows this is an irreversible mutating operation. The description adds the endpoint and the in-flight scoping but says nothing about idempotency, behavior on job completion, or whether partial results survive, which matters for 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?

A single sentence that front-loads the action and resource and tucks the endpoint into parentheses. No filler, nothing redundant.

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

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

For a one-parameter destructive stop operation with full schema coverage and annotations carrying the safety profile, the definition is adequate; no output schema exists so return values need not be described. The main omission is sibling routing and post-cancel effects.

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

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

Schema description coverage is 100% with a single job_id parameter already documented as 'Batch job id to stop'. The description adds no format, source, or lookup guidance beyond what the schema provides, 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?

Specific verb 'Stop' plus resource 'in-flight Batch job run', with the underlying endpoint (POST /jobs/:id/stop) pinned down. It is clearly distinguishable from batch_wait, batch_status and batch_results, though it never explicitly names those siblings or clarifies stop-vs-cancel semantics implied by the name batch_cancel.

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-flight' implicitly scopes usage to currently running jobs, which is useful context. However, there is no explicit statement of when to choose this over batch_wait or how to handle an already-finished/failed job, so 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 only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description carries the operational load. It discloses the automatic-mode default, that forcing js_render/premium_proxy disables automatic mode for the affected tasks and bills them at that configuration's cost, that premium_proxy is 10x cost, and what BATCH_ACCESS_DENIED means. This is exactly the cost/auth context an agent needs before invoking.

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 alternation/comparison, then billing semantics, then return values and error handling; every paragraph carries distinct information. Slightly dense and the cost/mode explanation is repeated for both js_render and premium_proxy, keeping it just short of a 5.

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

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

For a 10-parameter, no-output-schema tool this covers what the schema cannot: the default automatic mode, the cost consequences of overrides, the return shape (job_id + latest_run.status/stats), the sibling tools for polling, and the access-denied failure mode. An agent has everything required 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, but the description genuinely adds cross-parameter meaning: proxy_country works in automatic mode and requires premium_proxy when combined with js_render, and job-level vs per-task zenrows_params precedence. It does not restate the urls/tasks precedence rule already in the schema, which is the only real gap.

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

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

Opens with a specific verb+resource+scope: 'Submit a cloud Batch job that fans out many URLs asynchronously (Zenrows Batch API).' It then explicitly distinguishes itself from the nearest sibling ('NOT the same as browser_batch') and from scrape/extract by workload size, so the agent can route 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 ('large URL lists') and when-not ('scrape and extract handle single pages'), names the sibling it is not (browser_batch) with the distinguishing endpoint and auth header, and points to batch_status/batch_wait/batch_results for the follow-on workflow.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond them: pagination is handled server-side so the full list is returned, and result_url values are short-lived presigned links that expire and must be downloaded promptly.

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 paragraphs, front-loaded with pagination behavior, then the time-sensitive warning about expiring links. Every 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?

With no output schema, the description compensates by describing the returned row shape and the ephemeral result_url, plus the bounding behavior (returns full list). Nothing essential for a correct call is missing.

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

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

Schema description coverage is 100%, so the schema already documents job_id and the status filter with its default. The description names the row fields (task_id, external_id, status, result_url) but adds no detail about the job_id or status parameters themselves; 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 result rows for a Batch job'), which clearly separates it from siblings batch_create, batch_status, batch_cancel, and batch_wait. It does not explicitly name any sibling, but the purpose is unambiguous.

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

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

Usage is implied – list results of a job – but there is no explicit guidance on when to call this versus polling batch_status or batch_wait first, nor any stated prerequisite that the job must have relevant result rows.

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 the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's real contribution is naming the returned fields (latest_run.status + latest_run.stats), which partially substitutes for the absent output schema. It still says nothing about the set of possible status values or whether reads are eventually consistent.

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

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

One front-loaded sentence with the identifier and the returned fields packed in; there is no filler and nothing 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?

For a one-parameter read tool with no output schema, naming the returned fields is the right move and largely covers the gap. A brief note on polling cadence or status values would have made it fully self-sufficient.

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 job_id parameter is fully documented in the schema as 'Batch job id returned by batch_create'. The description adds no format or sourcing detail 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 (Get) and resource (status and stats for a Zenrows Batch job), which clearly separates it from batch_results, batch_cancel, and batch_wait in intent. It stops short of naming those siblings explicitly, so differentiation is inferable rather than delivered.

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

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

There is no when-to-use guidance, no mention of when to prefer batch_wait or batch_results, and no note about whether this is meant to be polled or called once. The agent must infer the workflow role from the word 'status' 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?

With annotations already declaring readOnly/openWorld/non-destructive, the description adds real context beyond them: the exact set of terminal states, and the credit-cap failure mode including the failure_reason value 'api_key_cap_reached'. It omits what happens when timeout_ms elapses before a terminal state, which is a notable gap for a wait 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?

Two compact sentences, front-loaded with the core action and its terminating condition, with the failure detail appended only where it adds value. No wasted phrasing.

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 wait/poll tool with annotations covering its safety profile and no output schema, the key facts an agent needs (what it polls, when it stops, one failure mode) are present. The missing piece is the behavior when timeout_ms expires without a terminal state, which an agent would want to know.

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 job_id and timeout_ms (with its default of 600000) are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb ('Poll') plus the resource it wraps ('batch_status') and enumerates the terminal states that end the wait. It implicitly differentiates from the sibling batch_status by describing the blocking-until-terminal behavior, though it never names batch_status as the non-blocking alternative directly.

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 conveys the usage context (wait until a job is done) through the enumeration of terminal states, which tells an agent this tool blocks rather than returning immediately. However, there is no explicit when-to-use vs when-not guidance, e.g. when a single non-blocking batch_status check is preferable, so usage is only implied.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses real behavioral traits: actions run sequentially, execution halts at the first failure unless stop_on_error is false, and per-step results map to the same index. It even flags that screenshots come back as base64 in the JSON unlike browser_screenshot. That is substantive context the 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 the purpose, then a usage sentence, then execution/return semantics, then a targeted note. Every sentence carries distinct information and none is padding, so the length is justified for a tool with 24 action types.

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

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

With no output schema, the description compensates by explaining that step results land in a results array at matching indices and that batch screenshots differ from browser_screenshot. Combined with the well-documented schema, an agent has enough to call it correctly; only a fuller description of what a result object contains is missing.

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

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

Schema description coverage is 100%, so all three parameters (session_id, actions, stop_on_error) are already documented in the schema, setting the baseline at 3. The description largely restates the stop_on_error semantics already in the schema; its extra detail about the results array concerns return values rather than parameter meaning.

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 ('Execute a sequence of browser actions in a single call against an existing session') and clearly distinguishes itself from the sibling single-action tools by contrasting 'a single call' with 'calling each tool individually.' An agent can immediately tell this is the batch variant of the browser action 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?

Gives a clear usage condition ('Use this when you already know the full sequence of steps') and an explicit alternative pairing ('faster than calling each tool individually'). It stops short of a when-not, e.g. that the batch is inappropriate when later steps depend on intermediate results, which the criteria for a 5 would require.

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, so the safety profile is covered structurally. The description adds nothing beyond that: no idempotency semantics (what happens if already checked), no failure mode for a bad selector, and no waiting behavior, which matters for a state-mutating browser tool.

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

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

A single short sentence with no filler, and the action is front-loaded. Its brevity is under-specification rather than excess, so it is efficient but earns no extra credit.

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 tool with full schema coverage, annotations covering the safety profile, and no output schema, this is minimally adequate. An agent can call it correctly, but the relationship to browser_uncheck and error/retry behavior remain undocumented.

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%: both session_id ('Session ID returned by browser_navigate') and selector ('CSS selector of the checkbox or radio element') are fully documented in the schema. The description adds no formatting or resolution detail, 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 ('Check a checkbox or radio button'), which is clearly distinct from siblings like browser_click and browser_fill. It does not, however, name its inverse browser_uncheck, so an agent must infer the boundary itself.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the direct alternative browser_uncheck or of browser_click for non-checkbox elements. The purpose sentence implies the use case but the description provides no routing help.

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 supply the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description usefully adds that the scope is ALL cookies and limited to the current browser session, but it does not say whether cookies are recoverable, whether other tabs are affected, or whether the call can fail on an invalid session_id.

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

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

One sentence, front-loaded with the action and immediately scoped. Nothing is wasted and nothing is buried.

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

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

For a single-parameter tool with full schema coverage, no output schema, and annotations covering safety, this is nearly complete. The only missing element is any statement of effect or irreversibility, which is minor for this operation.

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 session_id parameter is documented as 'Session ID returned by browser_navigate'. The description's phrase 'current browser session' loosely maps to that parameter but adds no format or error-handling detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('clear all cookies') with an explicit scope qualifier ('for the current browser session'), which distinguishes it from browser_get_cookies and browser_set_cookies in the sibling list. It does not name an alternative sibling, so it falls short of a 5.

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

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

There is no when-to-use guidance and no comparison to alternatives such as browser_get_cookies or browser_close. An agent must infer that this is for resetting session state before a fresh run; nothing in the text says so.

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, covering the safety profile. The description adds nothing beyond restating the action and selector mechanism; it does not mention potential side effects like navigation or form submission, nor what happens when the element is missing.

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

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

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

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

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

For a simple click tool with full schema coverage and annotations covering safety and open-world behavior, the description is minimally adequate. It omits prerequisites like needing an active session from browser_navigate and what happens when a selector does not match, though session_id origin is covered by the schema.

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

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

Schema description coverage is 100%, so both parameters are fully documented by the schema. The phrase 'using a CSS selector' merely echoes the selector parameter and adds no additional syntax or constraint.

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 (Click), resource (element on the page), and mechanism (CSS selector). It does not explicitly distinguish itself from siblings like browser_type or browser_fill, but the action is unambiguous.

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

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

No when-to-use or when-not-to-use guidance is provided. It does not mention alternatives such as browser_fill for input or browser_hover for mouseover, leaving the agent to infer from tool names 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=false, destructiveHint=false and openWorldHint=true, so the write/non-destructive profile is covered. The description adds genuinely new context — that closing releases 'all associated resources, including the concurrency slot' — which tells the agent about a quota/rate-limit effect not visible in 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?

A single front-loaded sentence with no filler; the most important fact (closing frees resources and the concurrency slot) is stated immediately.

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

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

For a simple one-parameter teardown tool with a rich schema and clear safety annotations, the description is nearly complete. Minor gaps remain — no error/idempotency behavior if the session is unknown or already closed — but nothing essential is missing.

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

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

Schema description coverage is 100%; the single session_id parameter is already documented as 'Session ID returned by browser_navigate'. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Close) and resource (a browser session), plus the side effect of freeing resources. It is unmistakable against siblings, though it does not explicitly name a counterpart tool the way the highest-scoring examples do.

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

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

Usage is only implied — the mention of freeing 'the concurrency slot' hints at when to call it (when you are done and need to release capacity), but there is no explicit when/when-not guidance or named alternative. Neither does it say whether it is safe to call on an already-closed 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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond them: no mention of whether HTML5 drag events fire, whether intermediate mouse moves occur, or what happens when the source or target selector is not found.

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 padding that states the action and its two endpoints. It is appropriately short, though it is arguably too thin to be maximally useful rather than verbose.

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

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

For a three-parameter interaction tool with full schema coverage and annotations covering safety, the description is minimally viable. It omits failure behavior, visibility/viewport requirements, and drag-event semantics, which an agent would want before invoking it in a browser 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 coverage is 100% and each of the three parameters is documented in the schema (session_id, source CSS selector, target CSS selector). The description merely restates the source/target relationship without adding format or syntax 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 ('Drag') and resource ('an element') with source and target positions, which clearly separates it from siblings like browser_click and browser_hover. It does not explicitly name those alternatives, but the action itself is unambiguous.

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

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

No guidance on when to use this versus browser_click, browser_hover, or browser_evaluate-driven drag scripts, and no prerequisites such as elements needing to be visible or in the viewport. The agent must infer the use case entirely.

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 openWorldHint=true and, notably, readOnlyHint=false (destructiveHint=false), implying the evaluated script can mutate page state — yet the description says nothing about mutation risk, sandboxing, timeouts, or error behavior. It adds essentially no behavioral context beyond the annotation block.

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 wasted words, which is appropriate for a one-line tool summary. It is efficient, though the brevity comes at the cost of the missing context noted elsewhere.

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

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

Arbitrary JS execution is a high-power operation with no output schema and no description of return-value serialization, error propagation, or whether the script runs in an isolated context. For this complexity level the one-liner leaves the agent guessing on key operational details.

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

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

Schema description coverage is 100%, so both script and session_id are already documented in the schema. The description adds nothing about the script argument's expected form (expression vs function body) or session_id provenance, 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 ("Execute") and resource ("JavaScript in the browser context") plus the return behavior. Among the many browser_* siblings, this is the only script-execution tool, so an agent can distinguish it, though the description makes no explicit sibling comparison.

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 reach for this versus browser_get_text, browser_get_html, extract, or other siblings. It states what it does but never when-not-to-use it or what alternative fits a read-only DOM need.

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, so the write/exploration profile is covered. The description's useful addition is that it clears existing content before setting the value — a nuance not conveyed by destructiveHint=false — but it says nothing about required page state, element type constraints, or what happens on a non-input selector.

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

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

A single sentence, front-loaded with the operation and immediately followed by the sibling disambiguation. Nothing is redundant and every clause earns its place.

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

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

For a three-parameter, fully schema-documented write tool with annotations covering safety and open-world behavior, the essential routing and semantics are present. Minor gaps remain around error/edge-case behavior (e.g. what happens if the selector matches a non-input element), which keeps it short of a 5.

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

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

Schema description coverage is 100% and all three parameters are documented in the schema, so the schema carries the burden. The description adds no syntax, format, or selector-interpretation detail beyond what the schema provides — the baseline 3 for full-coverage schemas.

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

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

The description pairs a specific verb ('Clear ... and set its value') with the resource (an input field) and explicitly contrasts it with the sibling browser_type ('appends instead'). An agent can distinguish this from browser_type 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?

It names the alternative tool by name and states the selecting condition: use browser_fill when you want to replace existing content, browser_type when you want to append. This is exactly the when/when-not/alternative guidance the tool needs given the near-identical sibling.

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, so the agent knows this mutates page state without being 'destructive'. The description adds one genuine behavioral detail — that focus may trigger focus-dependent UI changes (menus, validation, scroll) — but says nothing about what happens with non-focusable elements or timing.

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 compact sentence with the action front-loaded and no wasted words. Nothing could be trimmed without losing information.

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

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

With no output schema and both required parameters well documented, the description is minimally sufficient. It could go further by stating what occurs on failure or whether the tool waits for the element, but it covers enough for a simple two-param browser action.

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%: both selector and session_id are documented in the schema itself, including that session_id comes from browser_navigate. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Move focus to an element') and adds a consequence ('triggering focus-dependent UI changes'), so the action is unambiguous. It does not, however, distinguish itself from the many adjacent interaction siblings such as browser_click, browser_hover, or browser_press_key, which an agent may confuse with focusing.

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 use focus versus clicking, hovering, or typing into an element. The description implies the purpose but offers no conditions, prerequisites, or exclusions relative to the sibling interaction tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether the PDF is returned inline, saved to a path, or downloaded, which is the key behavioral question for a generation tool.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the brevity contributes to the missing usage and output information rather than being purely a virtue.

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 should explain how the generated PDF is delivered (bytes, URL, file path, download). It omits this entirely, leaving a real gap for an agent that must consume the result.

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

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

Schema description coverage is 100%, so scale, landscape, print_background, and session_id are fully documented in the schema with defaults. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Render) and resource (current page as a PDF document), which is unambiguous. It does not differentiate from the closest sibling, browser_screenshot, which also captures the current page but to an image.

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 choose PDF rendering over browser_screenshot, scrape, or extract, nor any noted prerequisites. The agent must infer the use case entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description usefully adds that the output is text enumerating roles, labels and states, but says nothing about behavior on large pages, truncation, or whether it requires the page to be fully loaded.

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

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

Three short paragraphs, front-loaded with the core action. There is mild redundancy between the second and third paragraphs, which both describe what the tree contains, but no wasted 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 correctly shoulders the job of describing return contents (roles, labels, states, selectors). It is nearly complete for a read-only single-param tool, missing only edge-case behavior like tree size limits or loading prerequisites.

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

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

There is a single required parameter (session_id) whose schema description is 100% covered ('Session ID returned by browser_navigate'). The description adds no further parameter meaning, 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 ('Get the ARIA accessibility tree of the current page') and characterizes the output as readable text. It implicitly differentiates from the screenshot sibling by noting the token advantage, but it never names an alternative tool 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?

Provides usable context: use it to see page structure and the selectors needed to drive interactions, and it is cheaper in tokens than a screenshot. It stops short of explicit when-not conditions or naming competing siblings like browser_get_html or browser_get_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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds no behavioral context at all: nothing about behavior when the selector matches multiple elements, when the attribute is absent (null? empty string?), or whether the page must already be loaded.

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

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

One short sentence, front-loaded with the verb and the scope, with no filler or redundancy.

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

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

There is no output schema, so the description should ideally state the return shape (string value, null/error when missing) and whether the element must exist. For a minimal getter with fully documented parameters and read-only annotations this is adequate but leaves real gaps.

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

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

Schema description coverage is 100%, so selector, attribute, and session_id are each documented in the schema, including attribute examples ('href', 'src', 'data-id'). The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource: retrieving the value of one named attribute on one element. This is distinguishable in principle from browser_get_text and browser_get_html, though the description never names those siblings or contrasts the scope. Clear but not sibling-differentiating.

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 statement of when to use this versus browser_get_html, browser_get_text, browser_evaluate, or browser_query_selector_all. The agent must infer that this is the single-attribute read path 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the scope of the read ('all cookies, current page') but says nothing about cookie scope semantics (domain vs page), httpOnly inclusion, or output format.

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 short sentence with the verb and scope front-loaded and no filler. Nothing could be removed without losing meaning.

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

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

For a simple read tool with full parameter coverage and complete safety annotations, this is close to adequate, but the absence of an output schema means the description should say what is returned (name/value pairs, count, format) and whether the scope is page or domain. The 'current page' framing may mislead on cookie scope.

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 sole parameter session_id is fully documented in the schema (100% coverage) as coming from browser_navigate, so the schema already carries the semantics. The description adds no parameter-level detail, which is the expected baseline when schema coverage is complete.

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 (Get) and resource (cookies) with a scope qualifier (current page), so it is clearly separable from browser_set_cookies and browser_clear_cookies by verb. The phrase 'current page' is slightly imprecise since cookies are domain-scoped, but the intent is unambiguous.

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

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

No guidance on when to use this versus alternatives such as browser_local_storage, browser_set_cookies, or reading cookies inside browser_evaluate. No prerequisites or context selection criteria are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the factual operation: no note on invalid-selector errors, on result size for full-page HTML, or on what happens if the element isn't 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?

A single front-loaded sentence with no filler; the scope contrast (element vs full page) is stated immediately. It is slightly redundant with the schema's selector description but wastes no space.

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

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

For a two-parameter read-only tool with a fully described schema, the description is minimally sufficient, and no output schema exists so return values need not be explained. It nonetheless omits practical caveats (large payloads, invalid selectors) that an agent would benefit from.

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 the selector description already stating 'omit for full page HTML'. The description's 'element or the full page' phrasing mirrors the schema without adding format or syntax 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 ('Get') and resource ('HTML source'), and clarifies the two scopes (element vs full page). It distinguishes itself from browser_get_text and browser_get_attribute implicitly, though it never names those siblings explicitly.

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

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

No when-to-use or when-not-to-use guidance, and no routing to alternatives such as browser_get_text for visible text or browser_get_attribute for a single attribute. The agent gets no help choosing among the many sibling getters.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description does add one genuine behavioral detail — only *visible* text is returned — but says nothing about hidden elements, whitespace normalization, or whether a missing selector/text yields an error or empty string.

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 14-word sentence with zero filler, and the primary scope (element vs. whole page) is front-loaded. Nothing needs trimming and nothing is buried.

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, read-only tool the definition is minimally sufficient, but with no output schema it never says what comes back (a plain string? concatenated visible text? empty on no match), and it omits the sibling routing that a crowded namespace like this one clearly needs.

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

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

Schema description coverage is 100%: the selector parameter already documents 'CSS selector of the element (omit for full page body text)' and session_id points back to browser_navigate. The description's 'entire page body' clause merely restates the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the visible text content') plus the two scopes (a single element or the entire page body). It implicitly distinguishes itself from browser_get_html by specifying 'text content', but it never names browser_get_html, browser_get_attribute, or extract as the alternatives an agent must choose between.

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

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

The description gives no when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this over browser_get_html when only readable text matters, or over browser_get_attribute for a single attribute, and no prerequisites (e.g. an active session from browser_navigate) are mentioned.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond them (no note about empty titles, iframes, or timing after navigation), but nothing is contradicted for a simple 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?

A single front-loaded sentence with zero filler. It is as short as it can be while still naming verb and resource, though it offers no structural cues for the workflow.

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-only accessor with full schema coverage and no output schema, naming the returned value (the page title) is sufficient for correct invocation. Only workflow hints are missing.

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

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

Schema description coverage is 100% and the lone session_id parameter is documented in the schema as originating from browser_navigate, so the description carries no additional parameter burden. Baseline 3 applies.

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

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

Specific verb ('Get') plus resource ('the title of the current page'), which cleanly separates it from siblings such as browser_get_url, browser_get_html, or browser_get_text. It does not explicitly name those siblings, so full differentiation is left to the agent.

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 schema note that session_id comes from browser_navigate hints at the workflow, but the description states no when-to-use, prerequisites, or alternatives. For a trivially scoped tool this is adequate but thin.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the 'current' qualifier (live session state) and nothing about return format or failure modes, so it neither contradicts nor substantially enriches the annotations.

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

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

A single front-loaded sentence with zero filler. Nothing redundant or padded.

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

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

For a simple read-only getter with a fully documented single parameter, the definition is nearly complete; the implied return value (the URL string) is obvious from the name and no output schema is needed. It could be marginally stronger by noting it reflects the live page state.

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

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

There is one parameter and schema description coverage is 100% — the schema itself explains that session_id comes from browser_navigate. The description adds no parameter detail, which is the expected baseline when the schema does the work.

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

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

Specific verb ('Get') and resource ('current URL of the browser session') make the tool's function unambiguous. It implicitly distinguishes itself from siblings like browser_get_title or browser_get_html, though it never names an alternative explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as browser_get_title or browser_navigate. The agent must infer that this is called to read the current page location, likely after a navigation.

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 openWorldHint=true, readOnlyHint=false, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds no behavioral context of its own: nothing about what happens when there is no prior history, whether it errors, or whether it waits for the page to load. It does not contradict the annotations, but it contributes nothing beyond them.

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

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

A single nine-word sentence with the action front-loaded and zero filler. Nothing needs trimming.

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, output-schema-less navigation tool the description is mostly sufficient, but it omits edge-case behavior (no back entry available, failure signalling) that an agent would need before calling it in a history-dependent flow.

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 session_id is already documented in the schema as 'Session ID returned by browser_navigate'. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Navigate back to the previous page in the browser history.' This distinguishes it implicitly from browser_go_forward and browser_navigate. However, it never names those siblings, so it falls short of a 5.

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

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

Usage is only implied by the purpose statement – an agent can infer it is used when it wants to return to a prior page. It gives no explicit when-to-use, when-not-to-use, or alternative routing (e.g., use browser_navigate or browser_go_forward instead).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds nothing beyond them: it does not say what happens if there is no forward history, whether the page reloads or triggers loads, or that session_id must reference an active session.

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 short sentence with zero filler, front-loading the action. Nothing is padded or redundant.

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

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

For a one-parameter navigation tool with annotations covering the safety profile, the description is minimally sufficient. It omits the no-forward-history case and any indication of the resulting page state, but no output schema exists and the schema documents the param, so the gap is small rather than critical.

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

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

Schema coverage is 100% and the single session_id parameter is documented in the schema as 'Session ID returned by browser_navigate'. The description adds no additional meaning about the parameter, 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+resource ('Navigate forward ... in the browser history'), so the action is unambiguous. It does not explicitly name or contrast with siblings like browser_go_back or browser_navigate, but the direction word 'forward' implicitly separates it from the back-facing tool.

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

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

Usage is implied by 'forward in the browser history' — an agent can infer this only applies when prior navigation has created forward history. There is no explicit statement of prerequisites (e.g., a prior browser_go_back or navigation), no failure-mode guidance, and no routing to alternatives such as browser_navigate.

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, covering the safety profile. The description adds only the mechanical action and does not explain side effects (DOM/CSS state changes, whether a subsequent click is needed), timing/wait requirements, or that it returns nothing useful.

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 tight sentence with the action front-loaded and no redundant or filler text. Nothing is 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?

For a simple two-parameter, non-destructive action with full schema coverage and no output schema, the description is sufficient to call the tool correctly. It could note that hover effects are transient and typically require a follow-up action, but the gap is minor.

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%: both selector and session_id are fully documented in the schema, including that session_id comes from browser_navigate. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('move the mouse cursor over an element') plus the intended effect ('trigger hover effects'), which distinguishes it in practice from browser_click, browser_focus, and browser_drag. It does not explicitly name or contrast with those siblings, so it falls short of a 5.

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

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

The phrase 'to trigger hover effects' hints at intent, but there is no guidance on when to prefer hover over siblings like browser_click or browser_focus, no prerequisites, and no exclusions. An 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?

The description discloses the three modes of operation, which is useful context beyond the name, but it says nothing about persistence across reloads, scoping to the current origin, or what happens to unrelated keys on clear. More importantly, the described 'clear' action deletes stored data while destructiveHint is false, giving the agent a contradictory safety signal for the most dangerous action.

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, listing the available operations before the scope qualifier. It is efficient, though arguably too terse to carry routing information.

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

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

With full schema coverage the parameters are covered, but there is no output schema, so the description should have clarified what 'get' returns (value? null when absent?) and whether clear affects the whole origin or just this session. For a multi-mode tool this leaves a meaningful gap.

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

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

Schema description coverage is 100%, so the schema already documents key/value/action/session_id semantics, including which are required per action. The description adds nothing beyond that, so the baseline of 3 applies.

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

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

The description names a specific resource (localStorage), the three operations (read/write/clear), and the scope (current page context), which is well beyond a tautology. It does not explicitly distinguish itself from adjacent siblings such as browser_evaluate (which can also touch page storage) or browser_get_cookies/browser_set_cookies, so it stops short of a 5.

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

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

There is no guidance on when to choose this tool over browser_evaluate, cookies tools, or direct JS execution, and no prerequisites are stated (e.g., that a page must be loaded/session established first). The three operations are implied by the verb list, but no when/when-not routing exists.

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 and openWorldHint=true, so the safety profile is partly covered. The description adds genuine behavioral context beyond them: it creates a session, returns a session_id consumed by all other browser_* tools, and crucially that the session holds one concurrency slot until browser_close releases 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-loads the core action, then lifecycle detail, then option guidance in a scannable list. Every sentence contributes, though the 'backed by Zenrows' hosted browser infrastructure' phrasing is mildly decorative.

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

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

For a three-parameter tool with no output schema, it covers purpose, session lifecycle, the returned session_id, the concurrency constraint, and when to use each option. Failure/error behavior on a bad URL or unreachable site is the only notable omission.

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

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

Schema coverage is 100%, so both proxy parameters are already fully documented in the schema (formats and examples included). The description adds the 'when to use' rationale for each option, which is useful but shallow, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Open a ... session and navigate to a URL') and explicitly frames itself as 'the entry point for all browser automation'. It distinguishes itself from the many browser_* siblings by declaring it creates the session_id that every other browser_* tool requires.

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

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

Provides the entry-point context and an explicit 'When to use options' block mapping proxy_country to geo-restricted content and proxy_region to geo-targeted proxies. It does not, however, state when to use this versus non-browser siblings like scrape or extract, so it stops short of naming exclusions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, which cover the mutation and safety profile. The description adds that a tab_id is returned for use with browser_switch_tab, useful context but limited. No additional behavioral traits like permissions or persistence are disclosed.

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 zero waste. The core action and return value are front-loaded, making it easy to scan.

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

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

Given the tool's simplicity, full schema coverage, and presence of annotations, the description is complete. It covers purpose and return value (compensating for the missing output schema) and links to the follow-up tool.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no further meaning about url or session_id. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Open a new browser tab.' Clear and distinct from most siblings. However, it doesn't explicitly contrast with browser_navigate, which also involves opening a URL, so the differentiation is only 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?

Mentions that the returned tab_id should be used with browser_switch_tab, implying a workflow. But it offers no explicit when-to-use versus alternatives like browser_navigate, nor any exclusions or prerequisites beyond what the schema shows.

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, so the safety profile is covered. Beyond that the description adds no behavioral context: no mention of focus requirements, whether the key is dispatched to the page or the browser chrome, or any side effects such as form submission on Enter.

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. It is efficiently sized, though the example enumeration is verbatim duplication of the schema and earns little of its space.

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

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

For a two-parameter tool with full schema coverage and safety annotations, the definition is minimally adequate. It leaves a real gap by not stating that the key is delivered to the focused element or noting modifier-combo syntax beyond the schema examples.

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 both session_id and key documented inline, so the baseline is 3. The description's example list merely repeats the identical examples already present in the key property description, adding no new meaning.

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 ('Press a keyboard key'), which is unambiguous and distinct from the click/type/fill siblings. However, it does not draw the boundary against browser_type or browser_fill, so the agent must infer the difference itself.

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

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

The description only supplies example key strings; it never says when to use this tool rather than browser_type, browser_fill, or browser_click, nor does it mention that a key event is sent to the currently focused element. Usage must be inferred entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful fact that it returns text, HTML, and attributes, but says nothing about behavior on zero matches, whether it waits for elements, result caps, or pagination.

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

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

A single well-formed sentence with no filler, and the operation ('find all matching elements') is front-loaded ahead of the return payload. It is efficient, though it could spend one more clause on disambiguation rather than staying this terse.

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 sensibly enumerates the returned fields (text, HTML, attributes), which is genuinely needed. However, for a browser-query tool in a large sibling set, it omits key context such as empty-result behavior and whether it requires the page to be already loaded.

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

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

Schema description coverage is 100%, so both session_id and selector are already documented at the schema level. The description adds no syntax, format, or defaulting detail beyond what the schema provides, making 3 the correct 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 gives a specific verb ('find all elements matching a CSS selector') plus the resource and the payload returned ('text, HTML, and attributes'), so an agent knows exactly what it does. It does not, however, distinguish itself from near-neighbours like browser_get_text or browser_get_html, which also retrieve element content.

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 statement of when to prefer this over browser_get_html, browser_get_text, browser_get_attribute, or browser_wait_for_selector. The intended use (bulk multi-element retrieval by selector) must be inferred from the name and the word 'all'.

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, so safety basics are covered. However, the description adds no behavioral context such as whether it waits for load, resubmits form data, or requires an active session beyond the parameter name.

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

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

The description is a single clear sentence with no wasted words and is front-loaded with the core action. It is appropriately sized for a simple 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 low-complexity, single-parameter tool with annotations and no output schema, the description is largely sufficient. It could mention the need for an existing session or post-reload behavior, but the schema and annotations cover the essentials.

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

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

There is only one parameter, and the schema provides 100% description coverage with 'Session ID returned by browser_navigate'. The description does not mention the parameter, so baseline 3 is appropriate.

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

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

The description states a specific verb (Reload) and resource (current page of a browser session), making the operation clear. It does not explicitly distinguish itself from sibling tools like browser_navigate or browser_go_back, so it falls short of a 5.

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

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

No guidance is provided on when to use this tool versus alternatives such as browser_navigate, browser_go_back, or browser_wait. The description only states what it does, leaving usage context entirely 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds use-case context but does not disclose the return format (image bytes vs. URL) or any capture limits, which is a meaningful omission for a screenshot 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?

Two tight sentences with no filler; the action is front-loaded and the routing condition follows immediately. Every clause earns its place.

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

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

For a 3-parameter read-only tool with full schema coverage and annotations, the description covers purpose and usage adequately. The main remaining gap is the absence of any note on what the tool returns, which matters more here because there is no output schema.

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

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

Schema coverage is 100%, so selector, full_page, and session_id are fully documented in the schema. The description's phrase 'current page or a specific element' only loosely maps to those parameters and adds no syntax or default details, 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 ('Take a screenshot') with explicit scope ('current page or a specific element'). It also names the sibling alternative (accessibility tree), so an agent can distinguish it from browser_get_accessibility_tree and browser_get_html without opening schemas.

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

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

Gives a clear condition for use ('visual verification') and an explicit alternative trigger ('when the accessibility tree is not sufficient'). It stops short of stating when not to use it (e.g., prefer text extraction for simple content), but the routing guidance is solid.

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 openWorldHint=true and destructiveHint=false, but the description adds no additional context such as whether the scroll completes synchronously, whether it triggers lazy loading, or how it interacts with the viewport state. The one sentence merely restates the schema.

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

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

A single front-loaded sentence with no wasted words, though the phrase 'in a given direction' is mildly redundant with the direction parameter already in the schema.

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

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

For a simple scroll action with full schema coverage, the definition is minimally viable, but it omits any note about whether scrolling is instant or animated, whether lazy content is triggered, or what the call returns (no output schema exists). An agent can call it, but not fully predict the effect.

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

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

Schema description coverage is 100% – direction's enum, the distance default of 500 pixels, and session_id's provenance are all documented in the schema. The description adds nothing beyond that, so the baseline 3 applies.

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

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

The description names a specific verb (scroll) and resource (the page) and the direction parameter, so an agent knows exactly what the tool does. It does not, however, distinguish itself from adjacent viewport tools such as browser_press_key or browser_evaluate, which can also move the page.

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

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

There is no when-to-use guidance: nothing says to call this before a screenshot, when content is below the fold, or that browser_wait may be needed for lazy-loaded content. No alternatives or exclusions are mentioned.

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 disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether change events fire, how an invalid value or missing option is handled, or whether the selection is verified. For a mutation tool this is a notable gap.

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

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

A single sentence with no filler and the key information (select, option, <select> dropdown) front-loaded. It is efficient, though its brevity edges toward under-specification rather than pure conciseness.

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

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

For a simple three-parameter tool with full schema coverage, annotations, and no output schema, the description covers the core action adequately. It omits failure behavior (option not found, hidden/disabled options) and event side effects, which an agent calling a stateful browser mutation would benefit from knowing.

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 value, selector, and session_id all documented, so the schema carries the parameter burden and the baseline is 3. The description adds only a marginal clarification that the selector targets a <select> element rather than any arbitrary node.

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

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

Names a specific verb ('select') and a specific resource ('option from a <select> dropdown element'), which is unambiguous on its own. It stops short of differentiating from near-siblings like browser_click or browser_fill, which could also target a select element, so it is clear but not sibling-aware.

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 statement of when to use this instead of browser_click, browser_type, or browser_fill, nor any prerequisite such as the select needing to be present or the session needing a prior browser_navigate. Usage context is left entirely to inference from the name.

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, so the safety profile is covered. However the description adds nothing beyond them: it does not say whether existing cookies are overwritten, whether cookies are session- or persistent-scoped, or whether a navigation is required first.

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 appropriately terse for a simple setter, though it verges on under-specification given the tool performs a write.

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 annotations carrying the safety profile and the schema documenting cookie fields in detail, the essentials are present. Still, for a mutation tool the description omits any note on overwrite behavior or session context, leaving a mild gap.

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

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

Schema description coverage is 100%, so both session_id and the nested cookie fields (name, value, domain, path, expires, secure, http_only) are fully documented structurally. The description adds no parameter detail, which is acceptable at this coverage but earns no bonus.

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 (Set) and resource (cookies) with scope (browser session), which distinguishes it from browser_get_cookies and browser_clear_cookies by name. It is clear, though it does not explicitly contrast itself against those siblings.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as browser_get_cookies or browser_clear_cookies. The agent must infer that this is the write counterpart to the cookie-reading tool.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, and the description adds nothing beyond restating the action. It does not explain side effects, such as whether focus persists for subsequent commands or whether switching invalidates other handles, which is meaningful for a stateful browser tool.

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

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

A single tight sentence with no filler and the purpose front-loaded. It is efficient, though it is so terse that it borders on under-specification rather than genuine conciseness.

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

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

For a simple two-parameter tool with no output schema, the description covers the core action adequately. It omits error/staleness behavior and the relationship to browser_new_tab, which an agent would benefit from knowing.

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 both parameters (session_id, tab_id) are documented in the schema, so the baseline is 3. The description adds no format, constraint, or provenance detail beyond what the schema already supplies.

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 (switch) and resource (browser tab) with the notion of focus, so the action is unambiguous. However, it does not distinguish itself from siblings like browser_new_tab, which also deals with tabs, leaving the agent to 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?

The description gives no when-to-use guidance, no prerequisites (e.g., that the tab must already exist), and does not reference alternatives such as browser_new_tab. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral detail beyond the annotations: content is appended by default rather than replaced, unless clear_first is set. It omits event/focus behavior, but that is a reasonable gap given annotation coverage.

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 no filler. The primary action comes first and the key behavioral caveat second, so every sentence earns its place.

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

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

For a simple typing tool with full schema coverage and annotations covering the safety profile, the description is largely sufficient and no output schema means return values need no explanation. Minor gaps around focus/wait behavior remain but are not critical to correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, which sets the baseline at 3. The description reinforces the clear_first parameter by explaining the default append behavior, but adds no format, syntax, or edge-case detail beyond the schema.

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

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

The description states a specific verb and resource ('Type text into an input element'), making the core action immediately clear. It also implicitly differentiates from the sibling browser_fill by describing append semantics, but it never names that sibling or explicitly contrasts the two, so it stops short of a 5.

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

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

Usage is only implied: the note about appending unless clear_first is set hints at when this tool is appropriate versus a value-setting tool. There is no explicit when-to-use, when-not-to-use, or named alternative, leaving the agent to infer the choice between browser_type and browser_fill.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds only the CSS-selector locating method and adds nothing about behavior when the element is not a checkbox, is already unchecked, or is missing.

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

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

A single front-loaded sentence with the action first and the qualifiers after; no filler, no redundancy.

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

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

For a two-parameter, simple mutation tool with annotations covering safety and full schema coverage, the description is essentially sufficient. Minor gaps remain around failure behavior and whether the target must be specifically a checkbox, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so both parameters (selector, session_id) are already documented in the schema. The description restates the selector idea but adds no syntax, format, or edge-case detail beyond what the schema provides, making the 3 baseline correct.

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 ("Uncheck a checkbox") plus the targeting mechanism (CSS selector) and context (browser session), which clearly separates it from browser_check. It never names that sibling, so differentiation is implied by the verb rather than stated.

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 purpose implies when to use it (when a checkbox needs unchecking), but there is no explicit guidance, no prerequisite that a session must already exist, and no pointer to browser_check for the inverse operation.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the wait is unconditional/fixed rather than event-driven, which is useful, but says nothing about blocking behavior, the 30s ceiling, or what happens if the session is closed. Adequate but thin against an already-covered annotation set.

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

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

Two short sentences, zero filler, with the core semantics front-loaded and the disambiguation second. Every word earns its place.

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

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

For a two-parameter tool with full schema coverage, annotations, and no output schema, the description covers the essentials. It omits only minor operational detail such as the blocking nature of the call and the maximum-duration caveat, which is already in the schema.

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

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

Schema description coverage is 100%: both ms and session_id are documented in the schema, including the 30000 maximum. The description adds no formatting, units, or default information 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 ('wait') and the scope ('fixed duration'), and immediately contrasts with the sibling browser_wait_for_selector. An agent can distinguish this tool from the selector- and navigation-based wait tools without opening any schema.

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

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

The second sentence gives the selecting condition by describing what the alternative does ('waits only until an element appears'), which implies this tool is for unconditional fixed delays. It is clear context, but it never states explicitly when to prefer a fixed sleep or warns about its cost, so no full 5.

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

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds the genuinely important behavior an agent cannot infer: only the *next* navigation event is observed, prior navigations are invisible and cause a full timeout wait, and URL-preserving updates produce no event at all. This is exactly the kind of blocking/gotcha disclosure that prevents a mis-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, front-loaded with the core behavior and followed by the two caveats; nothing is padded. Minor redundancy in restating the timeout default that the schema already specifies.

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

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

With a trivial return value and no output schema, the description supplies everything an agent needs: what triggers completion, what does not, and the timeout ceiling. Nothing material is missing for a two-parameter wait tool.

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

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

Schema description coverage is 100%, so the schema already documents session_id and timeout_ms including default and max. The description repeats the 30000ms default but adds no syntax or semantics beyond the schema, which is the expected 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?

States a specific verb and resource ('Wait for the page to navigate to a new URL') that cleanly separates it from browser_wait and browser_wait_for_selector, which wait on conditions rather than navigation events. 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?

The description gives clear context for when this tool works ('waits for the next navigation event') and two explicit failure conditions: an already-completed navigation is missed and the call blocks to timeout, and AJAX/SPA updates fire no navigation event. It stops short of naming the alternative to use in those cases (e.g. browser_wait_for_selector), so it is clear context without explicit redirection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context by defining 'stable in the DOM' as the wait condition and explaining the visible flag's effect, but it omits timeout behavior, what happens when the condition is never met, and any error/return semantics.

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

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

Two short sentences with zero filler, and the core wait condition is front-loaded before the optional modifier. Every clause earns its place.

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

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

For a three-parameter wait primitive with no output schema, the description covers the condition and the optional flag but is silent on the most operationally important unknown: what happens on timeout or if the element never becomes stable, and whether the call throws or returns a status. Annotations handle safety, so the gap is narrow but real.

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 session_id, selector, and visible are all documented in the schema itself. The description's restatement of the visible flag duplicates the schema text and adds no syntax, format, or edge-case detail beyond it.

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

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

States a specific verb (wait) and a specific resource (an element matching a CSS selector), with the exact condition being waited on (DOM stability). This clearly separates it from browser_wait_for_navigation, but the description never names or contrasts with the other wait siblings (browser_wait, crawl_wait, batch_wait), leaving differentiation to the tool name 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the alternative wait tools that exist in the sibling set. The agent must infer from the name that this is the right primitive before interacting with a dynamic element.

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, destructiveHint=false, and openWorldHint, but the description adds substantial behavioral context: conditional availability based on crawl output_format and content_status, exact return formats (raw HTML vs Markdown), max_chars truncation with default 20000, and a final note when truncation occurs.

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 follows with prerequisites, output behavior, and the alternative. Every sentence earns its place with no redundant or filler content.

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

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

Given no output schema, the description fully explains what is returned, in what format, how truncation works, and under what crawl conditions the tool can be used. It also routes to the correct alternative, leaving no critical gaps for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents crawl_id, content_id, and max_chars thoroughly. The description mostly repeats the same parameter information (content_id can be a content id or content_url from a crawl_results row; max_chars default 20000), adding little 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: reading a stored page of a URL from a crawl, in the crawl's output_format. It distinguishes itself from siblings by naming scrape as the tool for pages the crawl did not store, and by referencing crawl_results rows for content_id.

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

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

Explicitly states when the tool works: only for crawls created with an output_format, and only for results whose content_status is fetched. It also names the alternative (scrape) for pages not stored by the crawl, making the selection decision unambiguous.

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

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

Annotations only cover the read/write/open-world profile; the description adds the cost model ('Each page fetched is billed as one scrape'), the defaults (max_pages/max_items=100), non-obvious edge cases (start page never a result but still billed; a crawl matching nothing still costs one scrape; empty crawls end completed with no error), and two named failure codes with recovery guidance — far beyond 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?

Long but dense and front-loaded: the core purpose and cost warning come first, error codes last. Nearly every sentence carries operational information, though the billing/cost points are restated more than once and could be tightened.

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

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

For an async, mutable, open-world tool with no output schema, the description supplies return shape (crawl_id, status, crawl with coverage), the async follow-up chain (crawl_wait → crawl_results), and the error-code table. 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 the baseline is 3. The description still adds real semantic value: the cost implication of max_pages, the interaction between output_format and crawl_content, and the retry contract for idempotency_key. It does not, however, add anything for parameters the schema leaves thin (discovery, include/exclude syntax).

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 a crawl from one URL'), then precisely describes the mechanism: depth hops, pattern filtering, registrable-domain confinement. It explicitly names the sibling it is not ('For a single page, use scrape'), so an agent can distinguish it without opening another 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 ('one start page — a listing, category, blog index — and need the URLs behind it'), the alternative ('scrape' for a single page), and the follow-up workflow ('Call crawl_wait, then crawl_results'). Exclusions and the pattern-checking advice ('check them against the URLs the start page links to') are also present.

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: exact path resolution rules (~/.zenrows/crawls vs. absolute paths failing with INVALID_PATH), FILE_EXISTS behavior unless overwrite=true, partial:true semantics for in-flight pages after stop, and the hosted-server fallback returning a URL plus a command. This is rich, non-obvious operational detail an agent could not infer.

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 but front-loaded: the purpose and cheap-reply rationale come first, then path/overwrite rules, then lifecycle caveats. Every sentence carries information, though the three stacked paragraphs are at the upper edge of what's comfortable to parse.

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

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

With no output schema, the description carries the return-value burden and does so explicitly ('Returns the file's path and line count'). Error cases, partial results, and the hosted-server variant round out a complete picture for a 3-parameter write tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: path is relative to ~/.zenrows/crawls, an absolute or escaping path fails with INVALID_PATH, and overwrite's default-false FILE_EXISTS interaction is spelled out. The crawl_id parameter is not elaborated but the schema already covers it (c_…).

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 — 'Save every result of a crawl to one local file, as JSON lines' — and immediately clarifies the unusual return value ('the file's path and line count, not the results'). An agent can distinguish this from crawl_results/crawl_content 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?

Explains the context for re-invocation ('download again once crawl_wait says it ended'), the post-stop caveat with crawl_stop, and the hosted-server case where no file is written at all. What's missing is an explicit statement of when to prefer this over crawl_results; the contrast ('costs one small reply' vs. reading the file yourself) 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?

Goes well beyond the readOnly/openWorld annotations by decoding every status (running/completed/stopped/failed), the meaning of each stop_reason, credit-exhaustion cases, empty-result semantics, and the ok:false error codes. This is the behavioral context an agent needs and cannot get from the annotations.

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

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

The first sentence front-loads the purpose well, but the remainder is a dense run-on block mixing statuses, stop_reasons, and error codes without bullets or headings, which hurts scannability. It is informative but over-packed rather than tight.

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

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

With no output schema, the description carries the full burden and does so thoroughly: it details the returned fields, every status/stop_reason combination, error-code semantics, and pagination behavior. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% so the baseline is 3, and the description adds the key relational detail that next_cursor from a prior call is passed as cursor and that next_cursor is never null while a crawl runs. It does not elaborate on the limit parameter beyond the schema's default/max.

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 (get a crawl plus one page of kept URLs) and enumerates the returned fields (crawl_id, status, coverage, results, next_cursor). It explicitly differentiates itself from the sibling crawl_results for multi-page reads.

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?

Names the alternative crawl_results and the condition that selects it ('to read many pages at once'), and explains how to continue paging via next_cursor/cursor. It does not, however, distinguish itself from crawl_wait or crawl_list, so sibling routing is not fully 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?

Annotations already establish readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: result ordering, that entries are summary-only, and that next_cursor is absent on the last page, which is what an agent needs to terminate a paging loop.

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

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

Two sentences, front-loaded with what the tool returns before the paging mechanics. No filler, no restatement of the tool name 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 no output schema, the description carries the return-value burden and does so: shape (status and coverage), ordering (newest first), exclusions (no results), and the cursor contract. Nothing an agent needs to invoke and iterate this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes slightly further by spelling out the paging contract ('pass next_cursor as cursor') and the last-page sentinel, which the schema's terse cursor description does not convey. It stops short of restating the limit/default semantics.

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

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

States a specific verb (list), resource (crawls), account scope, ordering (newest first), and exactly what each entry carries (status and coverage). The '(no results)' parenthetical cleanly separates it from crawl_results, so an agent can route 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?

The '(no results)' qualifier implicitly tells the agent to reach for crawl_results when actual content is needed, and the pagination sentence gives the exact condition for the next call. It never names the alternative tool outright, so it falls short of an explicit when/when-not statement.

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

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

Annotations already establish read-only/safe, but the description adds substantial behavior beyond them: partial=true during a run, the 10-minute post-stop window where next_cursor stays set, the exact condition for next_cursor becoming null, and the content_status lifecycle (pending/fetched/failed). This is rich, non-obvious disclosure.

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

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

Three tight paragraphs, each front-loaded with the point (what it lists, what a result contains, pagination lifecycle) and no filler. Slightly longer than strictly necessary but 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?

With no output schema, the description fully carries the burden: it names the returned fields (url, content_status, content_url) and their meaning, plus the cursor lifecycle an agent must handle to call this correctly across runs.

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 semantics the schema lacks: next_cursor returns only URLs kept since the last read (incremental pagination) rather than a plain continuation. Limit behavior is left to the schema, which already documents it fully.

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), resource (URLs a crawl kept), and ordering/scope constraint (in the order it kept them, paginated up to limit). This clearly separates it from crawl_get (status), crawl_content (fetch body), and crawl_list (enumerate crawls).

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 operational context: call again with next_cursor while partial=true, and wait up to 10 minutes after a stop. It also routes the agent onward ('pass it to crawl_content as content'). It stops short of explicitly contrasting when to prefer crawl_get or crawl_wait instead, so it is strong context rather than full when/when-not guidance.

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

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

Goes well beyond the annotations: no billing for unfetched pages, in-flight pages still complete, no resume, idempotent behavior on an already-ended crawl, retry policy for 429/502/503/504 (3 retries, ≤50s total), the meaning of a 503 crawl_busy and CRAWL_BUSY, and the up-to-10-minute window where results keep growing.

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 the most decision-relevant facts (billing, no resume) before the operational details. Dense but nearly every sentence carries distinct information; the second paragraph is somewhat packed but not redundant.

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

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

With no output schema, the description still covers what a caller needs: final status on an idempotent call, billing behavior, retry/failure semantics, and the eventual-consistency window for results. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% for the single crawl_id parameter, and the description adds no syntax or format detail beyond it. Baseline 3 is appropriate when the schema fully documents the only parameter.

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

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

States a specific verb and resource ('Stop a running crawl') and immediately scopes it: pages still waiting are not fetched or billed, in-flight pages finish. It distinguishes itself from the read-side siblings by pointing to crawl_results for the URLs already kept.

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

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

Explains the context clearly: use it to halt a running crawl, then read retained output with crawl_results/crawl_get, and it cannot be resumed. It does not explicitly contrast against a hypothetical 'cancel' alternative, but the routing to crawl_results and crawl_get is unambiguous.

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

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

Goes well beyond the readOnly/destructive annotations: it discloses the timeout-retry contract, the progressToken progress-notification behavior, and the subtle semantic that a completed crawl with no results and no error is not a failure. This is exactly the kind of edge-case behavior an agent cannot infer from 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?

Front-loads purpose before routing, edge cases, retry, and progress details. Every sentence carries information, though the list of return fields and the parenthetical state enumeration make it slightly denser than strictly needed.

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

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

With no output schema, the description must convey return values and it does (status, counts, first_urls), plus timeout/retry behavior and progress notifications. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema coverage is 100% and the schema already documents both crawl_id and timeout (default 50, 60s client cancellation caveat). The description only alludes to timeout behavior via 'if the wait runs out first' and adds no parameter 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 ('Poll a crawl until it ends'), enumerates the terminal states (completed, stopped, failed), and names the return payload (status, counts, first_urls). It is clearly distinguishable from crawl_get, crawl_results, and crawl_download, which are explicitly referenced.

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

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

Gives clear routing guidance: after results, call crawl_download for one file or crawl_results for pages; if the wait times out, call crawl_wait again. It also points to crawl_get for the completed-with-no-results case. It lacks an explicit 'do not use when you only want a one-shot status check' exclusion, so it falls just short of 5.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the bar is low, yet the description adds substantial behavior: billing semantics (auto charges only for the succeeding configuration; forcing a config bills every request at 10x for premium proxies), fallback-on-unprepared-domain, and the meaning of the result flags 'empty' and 'noDataExtracted' plus the no-retry advice. This is exactly the operational context annotations cannot carry.

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?

Purpose and return shape are front-loaded, the mode list is scannable, and the closing note routes full-page needs to scrape. It runs long, but nearly every line carries behavior, cost, or mode-selection information, so little is wasted.

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

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

With 10 parameters, no output schema, and cost-bearing configuration choices, this would be easy to under-document. Instead the description covers mode selection, the automatic-vs-forced tradeoff, fallback behavior, and the shape and failure flags of the return value, which is enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter semantics the schema cannot: forcing js_render/premium_proxy disables automatic mode and changes billing, wait/wait_for are inert without js_render even in auto mode, and fallback_autoparse only applies to mode=auto. The css_extractor example also appears in the schema, so that portion is duplicative rather than additive.

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 ('Extract structured data from a webpage') and immediately narrows the output contract ('Returns JSON fields (products, articles, listings) rather than a full page body'). It also explicitly distinguishes itself from the sibling scrape tool for full-page content, 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?

The three modes (auto/autoparse/css) are each given a when-to-use condition, including the default and the fallback case (REQS007), and the description names the alternative tool ('Full-page markdown, HTML and screenshots come from scrape'). It further states when NOT to set js_render or premium_proxy and why.

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, openWorldHint, and destructiveHint=false, but the description adds substantial behavioral context: automatic mode only charges for the configuration that succeeds, forcing premium_proxy with js_render costs 25x a basic request, wait/wait_for require js_render, and response_type is ignored when structured extractors are set. This goes well beyond the annotation safety profile.

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 front-loads the core purpose and default mode, then uses short paragraphs and examples to cover forced configurations, alternatives, and costs. Despite its length for a 14-parameter tool, every sentence adds actionable 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?

With no output schema and rich annotations, the description supplies return types, default mode, the extract alternative, and important cost caveats. It still omits failure/timeout behavior and does not distinguish this stateless fetch tool from browser_* session tools or crawl_* multi-page tools, leaving minor gaps for a complex 14-parameter tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful parameter meaning: the cost interaction of premium_proxy plus js_render, the default automatic mode, and example payloads that show how parameters combine. Most individual parameter semantics are already in the schema, so it does not reach a 5.

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

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

The description states a specific verb and resource ('Scrape any webpage and return its content using Zenrows (Fetch)') and explicitly distinguishes the tool from the extract sibling for structured JSON fields. An agent can tell what this does and when the extract tool is more appropriate 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 concrete usage guidance: name the alternative for structured data ('the extract tool returns parsed fields'), state the default behavior ('Pass just the URL'), and explain when to force js_render or premium_proxy. However, it does not address when to choose this tool over the many browser_* or crawl_* siblings, so tool-level exclusions are incomplete.

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