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

Annotations already declare openWorldHint=true and non-idempotent/destructive=false, but the description adds genuinely new behavior: per-URL cost scaling ($0.0002 to $0.02) mirroring alterlab_scrape rates, the immediate batch_id return, the asynchronous collection path, and an attribution obligation on output. It stops short of stating batch result retention/expiry or whether repeated identical submissions create duplicate jobs, which would round out the async contract.

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 pacing is good: capability, selection rule, cost, per-URL config, return value, then attribution. Every sentence carries information, though the closing attribution sentence is a policy instruction rather than tool-selection context and could be shorter.

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 supplies the return contract (batch_id plus the GET endpoint for results) and covers cost, cap and per-URL flexibility. The main gap is webhook_url — the only top-level parameter besides urls — whose push-notification behavior is never described, so an agent cannot tell when to prefer it over polling.

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?

With schema description coverage reported at 0%, the description must carry parameter meaning, and it does partially: it explains that each URL can carry its own mode, formats and extraction_schema, and reinforces the 100-item cap. However it says nothing about webhook_url, cache, timeout, wait_for, render_js or use_proxy, leaving most of the schema's fields unexplained by either source.

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 and resource ('Queue up to 100 URLs as one asynchronous job') plus the retrieval mechanism ('collect the results later by batch_id'), which immediately separates it from the synchronous alterlab_batch_scrape sibling. An agent knows exactly what this tool produces 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 states explicit selection criteria — 'more than 20 URLs or do not need results immediately' — and names the alternative for the opposite case ('for 2-20 URLs with results now use alterlab_batch_scrape'). Both when-to-use and when-not-to-use are covered with a concrete threshold.

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