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

Annotations already indicate this is not read-only and is open-world. The description adds important context beyond them: the tool creates a free account, stores the API key on success, and enables retrying the original call. It does not describe failure behavior if the answer is rejected, so it falls short of a 5.

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

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

The description is three front-loaded sentences with no waste: purpose, usage condition, and success outcome. Every sentence contributes needed information.

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

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

Given the single-parameter schema, rich annotations, and absence of an output schema, the description is complete enough. It covers when to call the tool, what to pass, and what happens on success.

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 sole answer parameter is already documented as plain text with a maxLength. The description reinforces that the agent must provide the answer but adds no format, validation, or examples beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific action and resource: answer the signup question Zenrows asks before creating a free account. It also distinguishes this tool from siblings by limiting its use to cases where another Zenrows tool reports a signup question.

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 an explicit trigger: use only when another Zenrows tool reports a signup question. It also explains the full workflow: answer the question yourself, pass the answer here, then retry the original tool call.

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

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

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?

Beyond the 'destructiveHint' annotation, the description adds crucial behavioral details regarding resource consequences. It specifies that tasks in flight 'finish (and bill)' while waiting tasks are stopped and unbilled, which is essential operational context.

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

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

The description is dense and long, but every sentence serves a critical purpose, detailing state transition, billing consequences, and sibling comparisons. It is highly informative without being unnecessarily rambling.

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 complexity of job state management, the description is exceptionally complete. It clarifies not only what cancellation does but also the resulting state (results stay readable, pending tasks remain, idempotency details) for an AI agent to execute correctly.

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

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

Since the schema coverage is 100%, the schema already provides full semantics for the required 'job_id' parameter. The description does not add unique semantic value beyond confirming its necessity.

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

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

The description uses a specific verb ('Stop') and resource ('Batch job'), clearly defining the action. It distinguishes itself by stating the action is 'for good,' setting it apart from alternative state management actions like pausing or rerunning.

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

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

It provides explicit guidance on when to use this tool versus its close sibling, stating: 'To halt without ending the run, use batch_pause.' It also details the differential effect on waiting vs. in-flight tasks.

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

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

Adds substantial behavior beyond annotations: text results are inlined and truncated at max_chars with an explicit cut note, binary PDFs are never inlined and instead yield a 2-hour presigned result_url, large-run lookups can exhaust time and return a cursor, and the three named error codes plus the 14-day retention default are documented.

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

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

Front-loads what the tool does, then failures, in two tight paragraphs with no filler, and every clause carries operational information. The prose is dense and occasionally awkwardly phrased ('Finding that URL reads the run's results'), which slightly taxes readability.

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 return-value burden and does: inline text vs. result_url, truncation signaling, cursor continuation, and named error codes with their meanings. Nothing an agent needs to call or interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more: it explains max_chars' default and truncation note, the purpose of lookup_cursor as a continuation token, and that run_id defaults to the job's latest run. It contextualizes parameters rather than merely restating them.

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

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

States a specific verb ('Read') and resource ('one Batch task's stored result'), plus the exact keys (job_id, task_id) and their provenance ('from batch_results'). This cleanly separates it from batch_results, which lists rows rather than returning 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?

Explains the operating conditions thoroughly: when lookup_cursor appears and how to continue, and when to rerun after BATCH_RESULT_EXPIRED. It stops short of an explicit 'use this instead of batch_results when...' statement, leaving a small inference gap.

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 only covering write/open-world/safe profile, the description carries real behavioral weight: credit costs per configuration (1/5/10/25), billing rules for failed and 404/410 tasks, hard limits (100,000 tasks, 3 active jobs, BATCH_QUOTA_EXCEEDED), idempotency guarantees across retries, and the full error taxonomy with actionable codes. This is substantially beyond what readOnlyHint/destructiveHint/openWorldHint 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 and organized into labeled paragraphs (purpose, mode, cost, limits, returns/workflow, errors), so a reader can stop after the first two sentences. It is long, and the exhaustive error-code enumeration plus the cost paragraph border on verbosity for a tool-selection read, but each block is distinct and non-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?

There is no output schema, and the description compensates fully: it states what is returned (job_id, status, stats), that the job runs asynchronously, the ok:false/error.code/server_code failure shape, the ingesting:true behavior for 10,000+ task submits, and the exact follow-up toolchain. For a 12-parameter, 0-required async job creator, nothing an agent needs is missing.

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

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

Schema description coverage is 100%, and the schema itself already documents credits per flag, mode=auto default, idempotency-key reuse semantics, and the urls-vs-tasks precedence. The description's prose on 'Pass just the URLs' and 'Set js_render ... only to force a fixed configuration' largely restates that, so the baseline of 3 for a fully-covered schema is the correct ceiling.

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

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

The opening sentence names the verb and resource precisely ('Submit a Batch job: many URLs scraped asynchronously in the cloud') and immediately positions it against siblings, stating that 'scrape and extract handle single pages' and 'Not the same as browser_batch.' An agent can tell exactly what this does and what it does not, 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?

It gives an explicit selection rule ('Suited to large URL lists; scrape and extract handle single pages'), rules out a lookalike sibling ('Not the same as browser_batch'), and names the follow-up tools in sequence (batch_wait, batch_results, batch_content, batch_rerun). It even states what is out of scope (schedules, webhooks, exports, CSV inputs, open jobs are API/SDK-only).

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 and idempotentHint, but the description adds substantial context beyond them: what is destroyed (all runs and results), that in-flight runs stop picking up tasks at once, that the active-job slot is freed, that the job reads as not found immediately, and that storage cleanup happens in the background.

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

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

Front-loads the core action and outcome, then layers timing, slot behavior, idempotency, and the alternative in short declarative clauses. Every sentence carries distinct information with no filler.

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

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

As a destructive mutation with no output schema, the definition still covers destruction scope, immediate vs background effects, idempotency, and the safer alternative. Nothing an agent needs to call it correctly is missing.

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

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

Only one parameter (job_id) with 100% schema description coverage, so the schema already carries the semantics ('Batch job id returned by batch_create or batch_list'). The description adds nothing about the argument, so the baseline 3 for high coverage applies.

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

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

States a specific verb and resource ('Delete a Batch job with all its runs and results') and immediately distinguishes itself from batch_cancel by scope. An agent can tell it apart from siblings 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?

Explicitly routes the agent to the alternative: 'To keep the results, use batch_cancel instead.' The when-to-use condition for the destructive path versus the cancel path is stated outright, leaving nothing to inference.

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

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

The description adds significant behavioral traits beyond the read-only annotation. It specifies the sorting order ('newest first'), the data provided ('latest run's status and stats'), and crucial negative constraints ('Deleted jobs are not listed').

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 highly dense and efficient. It front-loads the core function and uses every clause to communicate a critical operational or structural requirement (sorting, filtering, paging).

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

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

The definition is comprehensive. It covers the scope (this account), the required output details (stats/status), the filtering mechanism, and the full pagination lifecycle, leaving no operational requirements ambiguous.

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?

While schema coverage is 100%, the description provides deep functional semantics for the parameters. Specifically, it details that `next_cursor` facilitates pagination and explains the practical constraint of when to stop iterating, adding context beyond the schema definition.

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 purpose is stated clearly and specifically: 'List this account's Batch jobs.' It effectively distinguishes itself from sibling tools like `batch_create` or `batch_cancel` by focusing exclusively on retrieval.

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

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

Usage guidelines are exceptional. The description details the specific filtering capabilities (status/type) and, crucially, outlines the precise pagination logic, advising the agent to 'keep paging until it is null.'

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: discloses that in-flight tasks still finish and bill, that a paused run still counts as an active job, that the operation is idempotent, and that an already-ended run returns its final status with already_ended:true. These are non-obvious behavioral traits the structured fields do not convey.

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

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

The action and its scope constraint are front-loaded in the first clause, followed by cost guidance, state semantics, and idempotency. Every sentence earns its place with no filler.

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

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

For a single-parameter mutation with no output schema, the description covers effect, billing implication, job-state implication, idempotency, and the already-ended return case. Nothing needed to invoke or interpret it correctly is missing.

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

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

Schema description coverage is 100% and the single job_id parameter is already documented as coming from batch_create or batch_list, so the schema does the heavy lifting. The description adds no extra parameter syntax or format detail; 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 (pause) and resource (a Batch job's current run), and immediately scopes the effect: no new tasks picked up. It distinguishes itself from batch_resume (the inverse) and batch_cancel (hard stop) without either schema being opened.

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

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

Explicitly names when to use alternatives: batch_resume to restart, batch_cancel 'for a hard cost stop.' It also clarifies the soft-stop semantics (in-flight tasks still finish and bill), so an agent can choose between pause and cancel on cost grounds.

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 mark this as a non-read-only, non-destructive, open-world write. The description goes well beyond that: billing ('Rerun tasks are billed like new ones'), the 10-day partial-rerun window, specific error codes, automatic Idempotency-Key handling, and the fact that it returns immediately while tasks ingest. This is unusually rich behavioral 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?

Front-loaded with the core action, then defaults, alternatives, constraints and errors in a logical order; nearly every sentence earns its place. It is dense and long, but the density is information rather than padding.

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 a mutation tool with no output schema and four parameters, the description supplies the missing pieces: failure modes, time window, idempotency guarantee, billing implication, immediate-return semantics, and the next call to make. Nothing an agent needs to invoke it correctly is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: what the default status set is and why, that status is ignored under full:true, and that full:true 'scrapes every task again.' The idempotency_key semantics largely restate 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 precise verb+resource with a precondition: 'Start a new run of a Batch job whose latest run ended (completed, stopped or failed).' This distinguishes it cleanly from sibling tools like batch_create (new job) and batch_resume (in-flight run), so an agent can route 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 names the default behavior (rerun failed/pending), the recovery scenario ('after a run that failed on credits or was cancelled'), and the alternative modes (status, full:true), plus the follow-up call to batch_wait. It stops short of explicitly contrasting with sibling tools such as batch_resume, so it is clear 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 readOnly/openWorld/destructive annotations: presigned result_url expiry (2 hours), 14-day retention, expired-row behavior, the BATCH_RESULT_EXPIRED error from batch_content, and partial lists while the run is still writing. This is exactly the operational context an agent needs.

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

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

Dense and front-loaded, with the paging mechanics first and return-shape second. Minor redundancy with the schema on limit defaults and the status enum, but every sentence is otherwise load-bearing.

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 of describing return values and does so thoroughly (task_id, external_id, url, metadata, status, type, result_url, error). Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter behavior beyond the schema: status filter semantics (processing = not finished, successful includes expired) and the warning that a sparse filter can return fewer rows than limit with next_cursor still set.

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 a Batch run's result rows, a page at a time') and scopes it clearly. An agent can immediately distinguish it from batch_content (reads a body) and batch_status (run state) 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?

Explicitly routes to alternatives with conditions: 'call batch_results again for a fresh one, or read the body with batch_content,' and explains the cursor continuation loop and the status filter options. The paging guidance ('keep paging' on sparse filters) removes inference.

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

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

Goes well beyond the annotations: billing semantics ('billed as they finish'), concrete return behavior on an ended run ('final status and already_ended:true'), and the exact credit failure codes (BATCH_INSUFFICIENT_CREDITS, BATCH_KEY_CAP_REACHED). This is the kind of operational detail the idempotentHint/destructiveHint flags cannot convey.

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

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

Two tight sentences plus a short credit footnote; every clause carries distinct information (action, billing, idempotency, ended-run return, error codes) and the primary purpose is front-loaded.

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

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

With no output schema, the description compensates by describing the important return signal (already_ended:true) and the failure modes, plus cost behavior. Nothing an agent needs to invoke this correctly against its siblings is missing.

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

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

Schema description coverage is 100% and the single job_id is fully documented as 'Batch job id returned by batch_create or batch_list'. 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 (Resume) and a precisely scoped resource (a paused Batch run), which an agent can distinguish from the counterpart sibling batch_pause. It does not explicitly differentiate from batch_rerun or batch_cancel, so sibling separation relies on inference rather than the text.

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

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

It establishes the precondition (only meaningful on a paused run) and describes behavior for the not-paused and already-ended cases, which functionally covers when the call is a no-op. It never names an alternative tool for those cases, so the routing guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description goes further by disclosing error semantics (ok:false with BATCH_INSUFFICIENT_CREDITS, BATCH_KEY_CAP_REACHED, AUTH_INVALID, BATCH_RUN_FAILED), server_code/failure_detail fields, and the paused:true / ingesting:true state flags. That is meaningful behavior beyond the structured fields, though it omits things like polling/rate expectations.

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

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

Front-loaded with the core purpose and return shape, then a compact paragraph covering failure, pause, and ingestion states. Dense but every sentence carries operational information; only the error-code enumeration feels list-heavy.

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 usefully compensates by naming the returned fields, the failure codes, and the paused/ingesting flags, so an agent can interpret a response. It stops short of describing polling behavior or how a non-terminal run should be followed up beyond the rerun hint.

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 job_id parameter is already documented as coming from batch_create or batch_list, so the schema carries the load. The description restates job_id as a returned field but adds no new constraint, format, or lookup semantics for the input.

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 a Batch job's latest run') and enumerates the returned fields (job_id, run_id, status, stats, job), which separates it from sibling tools like batch_results or batch_list that surface different payloads. The status enum values are spelled out, so an agent knows exactly what this tool reports.

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

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

It gives clear context for interpreting results and routes a failed run to batch_rerun as the recovery path. However, it never explicitly contrasts itself with batch_wait, batch_list or batch_results (e.g. 'use batch_wait to block until completion'), so the when-to-use boundary is inferred 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 declare readOnlyHint/openWorldHint/destructiveHint; the description goes well beyond by disclosing the timeout contract (ok:true, timed_out:true, retry note), the paused-run short circuit, the failed-run error envelope with enumerated error.code/server_code values, automatic retry of transient poll errors, and progress notifications when a progressToken is supplied.

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 each subsequent sentence covers a distinct outcome (timeout, pause, failure, retries, progress) with no filler. It is a dense single paragraph rather than a scannable structure, which costs it the top mark.

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 available, the description compensates by spelling out the return shape in each branch (ok/timed_out/paused/error.code) and the side-effect behavior around pause and resume. An agent has everything needed to call it and interpret the response.

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 job_id, timeout (default 50, 60s client cancel note) and the deprecated timeout_ms all documented in the schema itself. The description only alludes to the timeout indirectly ('If the wait runs out first') and adds no syntax or unit detail beyond what the schema already provides.

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

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

States a specific verb and resource ('Poll a Batch job until its run ends') and names the exact terminal states (completed, stopped, failed) plus the pause case. It also anchors itself against a sibling by saying it returns status and stats 'like batch_status', letting an agent distinguish the blocking variant from the immediate one.

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

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

Gives clear operating context: call it when you want to block until the run ends, re-call batch_wait if it times out, and note that a paused run will not advance until batch_resume. It stops short of explicitly saying when NOT to use it (e.g. prefer batch_status for non-blocking polling), so it is strong but not fully routing.

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

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

Beyond annotations that mark it destructive/open-world, the description discloses sequential execution, stop-on-first-failure behavior controlled by stop_on_error, results indexed by step, screenshot return format differences from browser_screenshot, and the fact that evaluate steps can mutate or delete page state.

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 gives usage guidance, execution behavior, result behavior, and one important caveat. Every sentence carries useful information for selection or invocation.

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

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

For a complex batch tool with no output schema, the description covers the critical return behavior: per-step results are in an indexed results array, failures stop execution unless configured otherwise, and screenshots are base64 strings. Combined with the rich action schema and annotations, this is sufficient 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 session_id, actions, and stop_on_error. The description still adds useful semantics about stop_on_error behavior and result indexing, though it does not need to re-document the fully enumerated action 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: execute a sequence of browser actions in a single call against an existing session. It distinguishes itself from the individual browser_* tools by explaining that it reduces round trips and is faster than calling each tool separately.

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 an explicit usage condition: use this when you already know the full sequence of steps. It also names the alternative strategy, calling each tool individually, and explains why batch is preferable in that situation.

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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered externally. The description adds useful scope by saying it clears all cookies for the current browser session, but it does not mention reversibility, auth requirements, or effects on active pages.

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, front-loaded sentence that states the action and its scope with no wasted words. It is appropriately sized for a simple browser operation.

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 low complexity, full schema coverage, and annotations that carry the destructive/open-world profile, the description is nearly sufficient for correct invocation. It could be strengthened by naming sibling alternatives, but nothing critical is missing.

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

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

Schema description coverage is 100%, and the single session_id parameter is fully documented in the schema. The description adds no parameter detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Clear all cookies for the current browser session.' It clearly differs from browser_get_cookies and browser_set_cookies, though it does not explicitly distinguish itself from the similarly named browser_clear_local_storage sibling.

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

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

It gives no guidance about when to use this tool versus alternatives such as browser_get_cookies, browser_set_cookies, or browser_clear_local_storage. The intended use is implied only by the tool name and description 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 destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully confirms the operation is a total wipe ('every entry') limited to the current page context rather than all tabs, but adds nothing about reversibility, permissions, or whether other origin storage is affected.

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 redundancy, sized correctly for a one-parameter destructive utility.

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 destructive utility with complete schema coverage, no output schema, and annotations carrying the safety burden, the definition is essentially sufficient. Only the absence of any usage context keeps it short of full marks.

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 session_id parameter, and the schema already documents it as the ID returned by browser_navigate. The description adds no additional 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 (Delete) and resource (every localStorage entry) scoped to the current page context. An agent can immediately distinguish it from siblings like browser_clear_cookies, browser_set_local_storage, and browser_get_local_storage 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 no when-to-use guidance, no alternatives, and no conditions under which the destructive wipe should be preferred over targeted removal via browser_set_local_storage. Usage is only inferable from the tool name, which is weaker than explicit guidance.

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

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

Annotations already declare readOnlyHint=false, 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 already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the bar is lower. The description still earns credit by concretizing the blast radius: cookies, storage and form data can be changed or deleted, which is more actionable than a bare 'destructive' flag. It does not discuss sandboxing, timeouts, or what the return value looks like.

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: the capability first, the risk second. No filler, no restating the tool name, and the most important caveat is not 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?

No output schema, and the description does say a result is returned, but not in what form (serialized? JSON-safe? errors thrown?). Annotations plus the destructive-state warning cover the safety picture well, so the remaining gap is small.

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 only two parameters, both documented in the schema (script semantics and session_id provenance). The description adds nothing about script syntax, serialization of results, or how errors surface, 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: 'Execute JavaScript in the browser context and return the result.' An agent can immediately tell this is the arbitrary-script escape hatch versus the many narrow siblings (browser_click, browser_get_text, etc.). It stops short of naming any sibling it supersedes, so 4 rather than 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 when-to-use guidance at all. Given the large set of purpose-built siblings, the description never says to prefer browser_get_text/browser_click and only fall back to browser_evaluate for cases they don't cover. The side-effect warning hints at caution but does not route the agent to an alternative.

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

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

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 safety is covered. The description adds the 'current page context' scoping detail, but does not say what happens if the key is missing or the page isn't loaded. With annotations doing the heavy lifting, a 3 fits.

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 waste, front-loaded with verb and resource. The 'current page context' qualifier earns its place by scoping behavior.

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

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

For a simple two-parameter read tool with full schema coverage and annotations declaring safety, the description is nearly complete. The only minor gap is not stating the result when a key is absent (null/error), which would help an agent interpret the call.

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 session_id and key are fully documented in the schema, and the description adds no format or syntax detail beyond it. The phrase 'one localStorage value' subtly confirms single-key semantics, matching the 'key' parameter, but this is baseline-level added value.

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

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

States a specific verb (Read) and resource (localStorage value) with scope qualifier 'one' and 'current page context'. This distinguishes it from browser_set_local_storage and browser_clear_local_storage, which mutate rather than read, though neither sibling is named explicitly.

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

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

Usage is implied by the read-vs-write/clear split among the localStorage siblings, but the description never states when to prefer this tool or what conditions apply (e.g., must be on a page, key must exist). No explicit alternatives are named.

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?

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 destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds a genuinely useful behavioral detail beyond that: the name/domain/path key determines replacement of an existing cookie, telling the agent what gets overwritten. It stops short of covering effects on subsequent requests or session persistence.

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 padding, with the core action stated first and the overwrite rule as a supporting detail. Nothing is redundant with the schema or annotations.

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

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

For a 2-parameter mutation tool with full schema coverage, rich annotations, and no output schema, the description covers the essential behavior including overwrite semantics. Only minor gaps remain (session prerequisites, effect on in-flight navigation), which are not critical 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 both parameters, and the nested cookie object fields (expires, secure, http_only, etc.) are fully typed in the schema. The description adds no parameter-level detail beyond what the schema already 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?

The description gives a specific verb ("Set") and resource ("cookies") scoped to "the browser session," so the operation is unambiguous. It does not explicitly name or contrast with siblings like browser_get_cookies or browser_clear_cookies, but the overwrite clause implicitly separates it from those read/clear operations.

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 tool versus alternatives, nor any stated prerequisites (e.g., that a session_id from browser_navigate must exist first). Usage is only inferable from the tool name and the session mention.

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=true, and openWorldHint=true. The description adds genuinely new context beyond those flags by stating that an existing value under the same key is replaced, which clarifies the overwrite semantics an agent needs before calling.

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

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

Two short sentences, front-loaded with the operation and followed by the one behavioral caveat. No filler or redundancy.

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

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

For a simple three-parameter write tool with full schema coverage and annotations carrying the safety profile, the description covers purpose and overwrite behavior. Only the session/prerequisite context is left implicit, which 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%, with all three parameters documented in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema provides, 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 (write) and resource (localStorage value) with scope (current page context). This cleanly separates it from browser_get_local_storage, browser_clear_local_storage, and browser_set_cookies without needing to name them.

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 'current page context' and the session_id parameter, but the description never states when to prefer this over alternatives like browser_evaluate or browser_set_cookies, nor any prerequisite such as requiring an active navigated 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, 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.