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

Beyond the annotations, the description discloses what is actually produced (free, watermarked, 15 seconds, in the page's language), how the result is delivered (link sent by e-mail), and the idempotency contract in plain terms ("Calling it again with the same page and address returns the same ad") – more concrete than the idempotentHint flag alone. It also surfaces the anti-abuse requirement that the address must originate from the user in this conversation.

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 short sentences, front-loaded with the action and result, then the trigger, then the hard constraint, then the repeat-call behavior. No sentence is redundant with the title or the 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?

With only two required parameters, 100% schema coverage, full annotations and an output schema, the remaining burden is behavioral – and the description covers output nature, delivery channel, language behavior and idempotency. An agent has everything needed to call this correctly or hand off to a sibling.

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 genuine constraint beyond it: the e-mail must be the user's own and supplied in this conversation, never inferred. That is a real interpretation rule the schema does not encode, though the url parameter gets no extra detail beyond the schema's note that social profiles fail.

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?

"Starts building a free watermarked 15-second video ad from a public web page" names a specific verb, resource, format, duration and pricing model in one clause. The scope qualifiers (public page, page language) let an agent distinguish it from get_ad_status and request_change 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?

"Use it when the user asks for a video ad for their site, product, app or store" gives a clear triggering condition, and the email constraint adds an explicit when-not (never guess the address, never use someone else's). It stops short of naming the sibling tools as alternatives for status checks or edits, so the boundary is implied rather than stated.

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