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

The description directly contradicts its annotations: it states 'Open-world: makes network requests to the target site' while openWorldHint is false, and it says it 'Writes vdd/clone-dataset.json, vdd/clone-manifest.json, and vdd/clone.md, overwriting any existing versions in place' while readOnlyHint is true. These are material safety-profile conflicts that would mislead an agent about the tool's side effects and reach.

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 paragraph is dense but front-loaded: purpose first, then artifacts written, then open-world caveat, then sibling routing, then parameter relationships. Every section carries distinct information, though the single-block format could be broken up for faster scanning.

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 complexity (9 parameters, multiple file writes, open-world crawl behavior) and the existence of an output schema, the description supplies the key operational context an agent needs: what gets written, overwriting behavior, network reach, and parameter roles. It would be a 5 if it did not conflict with the annotation layer.

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 baseline is 3, but the description adds meaning beyond the schema by clarifying that 'description is the target domain' (the schema calls it only 'Freeform description input') and by explaining the relationship among maxPages, timeoutMs, concurrency, crawl, browser, and refresh. This is useful disambiguation for a 9-parameter tool.

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 ('Crawl and capture a target domain into a clone dataset + manifest') and explicitly contrasts with the sibling phase pipeline ('it is not part of the VDD phase pipeline, so for the normal init→validate flow call those phase tools instead'). An agent can identify the tool's scope and its non-use case without opening another definition.

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 ('Use for cloning an external site') and when-not guidance ('not part of the VDD phase pipeline'), and names the alternative tools to call instead (init→validate phase tools). The boundary is unambiguous.

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