download_ad_creatives

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

With no annotations provided, the description carries the full burden, and it discloses meaningful behavior: files are written to out_dir, the directory is created if missing, each creative gets its own subfolder, videos are sampled to stills, and a manifest is returned. It doesn't address overwrite behavior or authentication/permissions, but it is substantially transparent for a download operation.

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 well-structured with an introductory purpose paragraph followed by Args and Returns sections. Every sentence adds value: the bulk-path context, the presentation use case, parameter details, and the return shape. No filler or redundant restatement of the tool name.

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 no output schema and no annotations, the description is remarkably complete: it covers the operation's side effects, each input, and the return structure. The only notable gap is unspecified behavior when out_dir already contains files or the manifest already exists, which could matter for repeated calls.

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%, but the description compensates fully by explaining every parameter: advertiser_name with examples, out_dir behavior, count with default and max, full_quality meaning, and frames default with its purpose. This is exactly what an agent needs beyond the bare 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 names a specific action ('Download'), a precise resource ('a whole advertiser's creatives'), and an output shape ('into one folder, with a manifest'). It also positions itself as 'the bulk path', distinguishing it from the single-creative sibling fetch_ad_creative without needing to open that tool's 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 clear context for when this tool is appropriate: collecting real ad examples for decks or reports, in bulk rather than one at a time. It doesn't name alternative tools explicitly or state when not to use it, but the 'bulk path' framing makes the intended use unambiguous.

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