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

With no annotations, the description carries the full burden and does well: it discloses the 50-entry ceiling, the defaults/override merge behavior, that the return is a raw API job response, the conditional uuid follow-up, and the paid-plan requirement. Async timing, rate limits, and failure behavior of the job are not described.

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 operation and the 50-URL cap, then layers in the option vocabulary, merge semantics, return behavior, and the paid-plan caveat. The parenthetical option list earns its space because the schema's additionalProperties does not enumerate valid keys.

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

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

No output schema exists, yet the description explains what comes back (the API's job response) and how to act on it (uuid → get_bulk_status → download_bulk_results). Combined with the nested-object merge semantics and plan restriction, an agent has everything needed to invoke and follow up correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it names the raw API option keys (file_type, width, height, full_page, ...) that the generic additionalProperties schema only gestures at, and it states the precedence rule — defaults apply unless an entry overrides them — which the schema does not spell out.

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 — submits up to 50 URLs as one bulk screenshot job over the JSON bulk API — and the 'JSON bulk API' phrasing implicitly separates it from the bulk_screenshots_csv sibling and from the single-URL take_screenshot. An agent can identify the operation and its batch scope without opening the schema.

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

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

Gives a clear usage path: submit here, then track with get_bulk_status if a uuid comes back and fetch with download_bulk_results, and it flags the 'Paid plans only' prerequisite. It stops short of stating when to prefer bulk_screenshots_csv or take_screenshot instead, so the routing to the closest sibling is left implicit.

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?

No annotations exist, so the description carries the full burden and does well: it discloses the CSV contract (a 'url' column with full https:// URLs, other columns mapped to API option names), the asynchronous job model with an email notification side effect, and the paid-plan restriction. It omits failure behavior, row limits, and whether partial failures are tolerated.

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 dense sentences, front-loaded with the action, then the input contract, then the return/follow-up, then the pricing gate. No sentence is filler.

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

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

With no output schema, the description correctly covers the return value (job response with uuid) and the follow-up tools plus the email fallback. It leaves the async timing, row limits, and error semantics undefined, which is a modest gap for a job-submission 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 earns more by explaining the CSV row/column semantics that the schema only hints at — the 'url' column requirement and that extra columns become render options named after API parameters. The csv_path vs csv_content precedence is already in the schema.

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

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

States a specific verb and resource ('Uploads a CSV to start a bulk screenshot job') and the CSV format is a strong implicit differentiator from the sibling bulk_screenshots. It never names that sibling explicitly, so the differentiation is inferred 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?

Explains the input choice ('Pass either a local csv_path or the CSV text in csv_content') and routes the agent forward to get_bulk_status and download_bulk_results after the uuid is returned. It adds a real precondition ('Paid plans only') but gives no explicit when-not-to-use guidance versus bulk_screenshots.

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 no annotations, the description carries the full burden and does well: it discloses the return shape (one row per URL with status, hosted screenshot URL, error message) and the prerequisite that the job must be finished. It omits permissions, delivery mechanism (file vs. inline payload), and behavior on incomplete/expired jobs.

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

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

One sentence, front-loaded with the action and resource, followed by the return detail. No filler, 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?

Since there is no output schema, describing the row structure is essential and is done here; the job-completion prerequisite is also covered. The main residual gap is whether 'downloads' yields a file/artifact or a JSON payload, which an agent would want to know before calling.

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 uuid parameter is already documented as the job uuid from submission. The description only reinforces 'by uuid' and adds no format, example, or validation detail beyond the schema; 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 (downloads the results of a bulk screenshot job) and specifies the input that identifies it (uuid). It is clearly distinct from siblings like get_bulk_status (status check) and bulk_screenshots (job submission).

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 'finished bulk screenshot job' tells the agent this is only applicable after completion, implying get_bulk_status as the prior step. However, it never names that sibling or states explicitly what to do if the job isn't finished, so routing is inferred rather than directed.

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 no annotations, the description carries the burden and does well: it names the return artifact (hosted PDF URL), discloses the default single-long-page behavior and how format/width/height change it. It stops short of 5 because cost/credit implications (only hinted at indirectly) and error behavior are left to 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?

Front-loaded with the core action and output, then capabilities, then save_path. Dense but every sentence contributes; the parenthetical option list is a bit packed but not wasteful.

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 46-parameter tool with full schema coverage and no output schema, the description adequately frames the tool's purpose, output, and the single most important parameter interaction (format vs continuous page). Deep behavioral details like caching credits are delegated to the schema, which is acceptable at 100% coverage.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning by explaining the interaction between format, width/height and continuous-page output, and clarifies save_path semantics. It adds value beyond the per-field schema text for the most consequential parameters.

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

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

States a specific verb+resource+output: 'Renders a URL or raw HTML in a real browser and converts it to a PDF, returning the hosted PDF URL.' An agent can distinguish it from take_screenshot and scrape_page by the PDF output and the hosted URL, even though siblings aren't 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?

Gives clear selection guidance within the tool: use 'format' for paginated output, omit it for one continuous page, and use save_path to also save locally. It doesn't explicitly route to siblings like take_screenshot or scrape_page, so it stops just short of a 5.

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

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

No annotations exist, so the description carries the full burden. It discloses the return payload (percent, success/fail counts) and the completion handoff, which is genuinely useful. It says nothing about behavior on an unknown or expired uuid, whether failed URLs are retryable, or job retention, which are material gaps for a polling tool with no structured safety hints.

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, no waste, and the effect (progress read) is front-loaded ahead of the next-step instruction. Nothing could be cut without losing routing information.

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

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

There is no output schema or annotations, but the description compensates by summarizing the return fields and the completion workflow, which is sufficient to call this correctly. Only error/expiry behavior is left unaddressed, a minor gap for a one-parameter read tool.

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

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

Schema coverage is 100% with a single required parameter whose description already says it is the job uuid returned at submission. The description's 'by uuid' adds no syntax, format, or provenance information beyond the schema. Baseline 3 applies when the schema does all 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?

States a specific verb (returns the progress) and resource (bulk screenshot job by uuid) and enumerates the payload: percent complete plus successful and failed URLs. The agent can distinguish it from download_bulk_results, which is explicitly named as the follow-up rather than an alternative.

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?

Clear usage context: call it to poll a job, and call download_bulk_results once progress hits 100%. That sequencing is exactly what an agent needs. It doesn't state what to do on a failed or stalled job, and there are no explicit exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the returned artifact (hosted video URL), supported formats, the cost warning that rendering is slower than a screenshot, the optional scroll-back and viewport-recording behaviors, and that sizes produces multiple recordings. It does not discuss authentication, rate limits, local file saving behavior, or what happens on partial failure, which keeps it from 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 five tight sentences with no waste. It is front-loaded with the core purpose and output, then moves to the key mode switches and the performance warning, all of which are useful for selection.

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 41-parameter tool with no annotations and no output schema, the description covers the essential modes, output artifact, and cost profile needed to select and invoke it correctly. It is slightly thin on the many advanced rendering options, but since the schema fully documents those, the description is largely complete.

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

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

Schema coverage is 100%, so the schema already documents all 41 parameters and a baseline of 3 would be acceptable. The description still adds useful meaning beyond the schema by clarifying the non-obvious semantics of video=true (viewport recording without scrolling), sizes (multiple viewports in one request), duration, scroll speed, and scroll_back, though most of the 41 parameters are not discussed in the description.

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 — recording a video of a browser scrolling a web page — and names the output formats and returned artifact (hosted video URL). It also distinguishes the non-scrolling 'video=true' mode and the multi-size mode, so an agent can tell exactly what this tool does and how it differs from screenshotting.

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

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

It gives concrete usage guidance for the main modes: 'Set video=true to record the viewport without scrolling (for animations or live dashboards)' and 'Pass sizes to record the same page at several viewport sizes in one request.' It also implicitly contrasts with the sibling take_screenshot by warning that rendering takes noticeably longer than a screenshot, but it does not explicitly say when to prefer take_screenshot or generate_pdf 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?

With no annotations, the description does most of the work: it discloses that a real browser renders the page with JavaScript executed, that extracted files are fetched and returned inline, that output is truncated to max_content_chars, and that a screenshot is included and "counts as one credit", which is a billing behavior not visible in the schema. It still omits auth/rate-limit expectations and failure behavior for a 36-param 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?

Five sentences, front-loaded with the core verb and output formats, then the inline/truncation behavior, then the JS-site rationale, then cost. Each sentence carries information, and the length is reasonable for a 36-parameter tool, though the screenshot/credit sentence could be merged or moved.

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

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

For a tool with 36 parameters and no output schema, the description should clarify the return shape, but it only says files are fetched and returned inline and truncated, without describing the response structure or how the screenshot relates to the extraction output. It is adequate given the rich schema, but it leaves real gaps around return values and error behavior.

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

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

Schema coverage is 100%, so the schema already documents all 36 parameters thoroughly, making 3 the baseline. The description adds only marginal meaning: the tradeoff between Markdown and other extract modes, and the truncation role of max_content_chars; it leaves the other 34 parameters entirely to the schema.

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

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

The description has a specific verb and resource: loads a page in a real browser and extracts Markdown, text, HTML, or image URLs. It distinguishes itself from plain HTTP fetches ("JS-heavy sites that plain HTTP fetches can't read") but never contrasts with its actual siblings take_screenshot or generate_pdf, even though it notes a screenshot is captured as a side effect, which blurs the line with take_screenshot.

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

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

"Works on JavaScript-heavy sites that plain HTTP fetches can't read" and "Markdown (best for reading and summarizing)" imply when to prefer this tool and which extract mode to pick. However, it never says when to use take_screenshot or generate_pdf instead, and it has no explicit exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden and does well: it discloses that each call consumes one screenshot credit, that cached captures are free, and that a URL is always returned even when inline rendering is suppressed. It omits auth/prerequisite needs and timeout/error behavior, keeping it short of a 5.

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

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

Three sentences, front-loaded with the core action and return value; the long capability clause is dense but justified for a 51-parameter tool. The middle sentence is a borderline run-on list, which costs a point but costs little comprehension.

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, but the description states what is returned (hosted URL, conditional inline image) and the cost model, covering the essentials for a 51-param, zero-required-parameter tool. Multi-size output (sizes array, one image per size, no inline) is only documented in the schema, leaving a small gap.

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

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

Schema coverage is 100%, so the schema already documents all 51 parameters including enum values and examples; baseline is 3. The description's capability enumeration (selector, clip, retina, blocking, injection, cookies, proxy, geolocation) helps an agent know what surface exists without scanning 51 fields, but adds no syntax or defaults 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?

Specific verb + resource ("Captures a screenshot of a web page (or of raw HTML) in a real browser") plus what it returns ("hosted image URL"). The raw-HTML variant and the capture modes make it clearly distinct from scrape_page, generate_pdf, and record_scrolling_video.

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 default inline-render behavior and the full_page exception with the include_image=true override, which is exactly the kind of when-to-use nuance an agent needs. It stops short of explicitly excluding siblings (e.g., 'for PDFs use generate_pdf' lives only in the schema), so no explicit alternative routing in the description.

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