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

With no annotations, the description carries the full burden and does so fairly well: it states the blocking/polling behavior (poll_interval, timeout defaults), discloses that exceeding the timeout raises RuntimeError, and warns that 'json' formats use Workers AI and incur additional charges. It does not mention auth requirements or the exact failure modes beyond timeout, keeping it just 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 prose is front-loaded and tight, and the long Args block is justified by 22 undocumented parameters, each receiving a single compact line. Slightly verbose in places (multiple multi-line nested-key explanations), but there is essentially no wasted sentence.

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

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

For a high-complexity, high-parameter tool, the description covers purpose, sibling routing, every parameter, cost implications, and the return/error contract ('same shape as crawl_status', RuntimeError on timeout). An output schema exists, so return-value detail is appropriately left out; 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 description coverage is 0% across 22 params, so the description must compensate entirely — and it does, documenting defaults, ranges (limit max 100000, max_age max 604800), enum values (source, formats, crawl_purposes, reject_resource_types), priority rules (exclude_patterns 'takes priority'), pattern syntax (* vs **), nested keys for json_options/goto_options/wait_for_selector, and concrete examples for authenticate/extra_http_headers/cookies.

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

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

Opens with a specific verb+resource ('Start a crawl and wait for it to complete, returning the final results') and explicitly identifies itself as a composition of crawl_start and crawl_status, which cleanly distinguishes it from those siblings. An agent can tell what it does and how it relates to the other crawl 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?

Gives an explicit when/when-not: 'Suitable for small crawls (few pages). For large crawls, use crawl_start and crawl_status separately to avoid timeout issues.' That names both the alternative tools and the condition that selects them, leaving nothing to inference.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return shape but says nothing about idempotency, whether a finished job can be cancelled, whether cancellation is immediate, or permission requirements — significant gaps for a mutation 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?

Front-loaded with the action, then scoped Args and Returns sections. Efficient, though the Returns line partially duplicates the existing output 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?

The output schema means return values need not be explained, and the single parameter is covered. But for a mutation with no annotations, the description omits operational semantics (idempotency, post-cancel state) an agent would want.

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 0%, so the description must compensate, and it does: it identifies job_id as 'the crawl job ID returned by crawl_start,' giving the agent both meaning and provenance for the sole 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 ('Cancel a running crawl job') that cleanly distinguishes it from siblings like crawl_start, crawl_status, and crawl_list. No explicit sibling reference is needed given the distinct action.

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 'running crawl job' implies a precondition (only an in-flight job can be cancelled), which is mild usage guidance. However, there is no explicit when-to-use/when-not guidance, no mention of what happens if the job already finished, and no routing to alternatives like crawl_and_wait.

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 disclose meaningful behavior: the data source (local database), the lifecycle that populates it, and pagination defaults. It stops short of stating read-only semantics explicitly or any concurrency/rate behavior, but the listing nature makes the safety profile inferable.

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 one-line purpose, then lifecycle context, then parameters. The Args section is dense and every line adds information not present in the schema's bare titles.

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?

Parameters and lifecycle are completely covered, and for a simple list tool that is nearly everything an agent needs. The Returns block duplicates an existing output schema, which is redundant rather than harmful, and no filtering-by-URL or ordering behavior is mentioned.

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 0%, so the description must compensate, and it does fully: it enumerates every valid status_filter value (which the schema does not), and documents limit/offset defaults and pagination purpose. Nothing about the parameters is left undocumented.

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 all crawl jobs stored in the local database"), which clearly separates it from action siblings like crawl_start or crawl_cancel. It doesn't explicitly name a sibling it overlaps with (e.g., crawl_status), but the purpose is unambiguous.

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

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

Explains the data model context that tells an agent when this is useful: jobs exist only after crawl_start/crawl_and_wait, and status is refreshed by polling crawl_status. It gives clear context but no explicit when-not or alternative-selection 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?

With no annotations, the description carries the full burden and does well: it discloses that the job is asynchronous and returns immediately, that 'json' format incurs Workers AI charges, that render=false is faster and unbilled, that exclude_patterns take priority over include_patterns, and that reject_resource_types speeds up crawls. It omits rate limits, credential/auth requirements for the API itself, and error/failure behavior, so it falls short of exhaustive.

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

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

Front-loads purpose, async contract, and sibling routing in the first two sentences, then uses a structured Args/Returns layout. Given 20 parameters and 0% schema coverage, the length is justified and every line 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?

An output schema exists, so return values need little explanation, and the description still briefly states the shape ({job_id}) and its use. Combined with the thorough parameter documentation and sibling routing, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 0%, yet the description documents all 20 parameters with defaults, valid ranges (limit max 100000, max_age max 604800), allowed enum-like values ('all'/'sitemaps'/'links', formats), priority rules, and concrete examples for nested objects like authenticate, cookies, and goto_options. It fully compensates for the empty schema.

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

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

States a specific verb and resource ('Start an asynchronous crawl job using Cloudflare's Browser Rendering Crawl API') and immediately clarifies the async contract by noting it returns a job_id. It distinguishes itself from siblings by naming crawl_status and crawl_and_wait as the follow-up tools.

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

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

Explicitly routes the agent: 'Use crawl_status to poll for results, or use crawl_and_wait to block until completion,' and mentions crawl_cancel in the Returns section. The alternative-selection conditions are stated rather than left to inference.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose a genuine behavioral trait beyond structured fields: results over 10 MB return a cursor that must be passed back to paginate. It also enumerates the job-level status values (including timeout/limit cancellations), though it omits auth requirements, error behavior for unknown job_ids, and rate limits.

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

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

Front-loaded with a one-line purpose, then pagination behavior, then Args and Returns sections — well structured and easy to scan. The large Returns block is somewhat verbose given an output schema already exists, but it is clearly delineated and each line carries information.

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

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

An output schema exists, so the description need not explain return values, yet it still documents pagination and all parameters completely for a 4-param tool. The only meaningful omissions are failure modes (invalid/expired job_id, what an errored job returns) and any permission requirements.

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 0%, so the description must compensate entirely, and it does: job_id's origin, cursor's role as a pagination token from a prior response, limit as records-per-page, and status_filter's full closed set of six values. This is exactly the meaning the bare schema lacks.

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 the status and retrieve results of a crawl job') that an agent can act on immediately. It references crawl_start as the source of job_id, which gives partial routing help, but it does not distinguish itself from crawl_and_wait or crawl_list, which also relate to crawl jobs.

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

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

Usage is implied rather than stated: job_id comes 'from crawl_start', so the tool is meant to be called after starting a job, and the cursor paragraph explains how to continue paging. There is no explicit when-to-use-vs-alternative guidance (e.g. versus crawl_and_wait) and no exclusions or prerequisites such as job lifetime or auth.

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