Generate ad image

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

All four annotation hints are false, so the description carries the full disclosure burden and meets it. It discloses that the tool spends credits, that saved-brand hydration can silently swap the engine to the compositing model, that raw:true sends the prompt byte-identical with no rewriting/guidance/negative-prompt, and that delivery and validation are unchanged. This is deep, honest behavioral disclosure far beyond what annotations provide.

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 core purpose and output, and every sentence carries distinct value (engine behavior, multi-brand caution, raw semantics, cost, timing). It is slightly dense and run-on in the engine/multi-brand passages, but contains zero filler, so it earns a high score despite the parsing effort.

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 complex tool with 7 parameters, subtle mode interactions, cost implications, and no output schema, the description is remarkably complete. It covers the deliverable (served URL), engine-selection behavior, brand hydration caution, raw mode, cost (credits), durability, and the capabilities catalog for model ids. An agent has everything needed to call it 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 coverage is 100%, but the description adds genuine cross-parameter semantics the schema cannot express alone: the interaction between refImages, useBrand, model, and raw (e.g., 'a model you named is only honoured when no references ride — pass raw:true (or useBrand:false)'). It also clarifies that model is 'a catalog id from hermoso_capabilities (omit for the default),' connecting to a sibling capability tool. This is additive meaning, not duplication.

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 opening sentence states a specific verb, resource, and output: 'Render a finished ad IMAGE and return its served URL.' This clearly distinguishes generate_image from video/voice/text siblings (generate_video, generate_voice, generate_text) and names the core deliverable. It also lays out distinct modes (compositing vs raw) that define the tool's scope.

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?

Provides rich, actionable usage context: when to pass refImages for product-accurate compositing, the explicit MULTI-BRAND CAUTION instructing to pass the fresh brand's productImages and set useBrand:false, and when to use raw:true to guarantee the named model renders. Lacks only an explicit routing against sibling image tools like render_ad or make_template_ad, which keeps it a 4 rather than a 5.

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