Generate object composite

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

Annotations already declare readOnly=false, openWorld=true, and idempotent=false, so the safety profile is covered. The description usefully adds three facts beyond the annotations: it consumes Firefly Services credits (a real cost implication), it returns Adobe output URLs, and wait=false yields an async job. It omits that 'confirm' must be true to actually spend credits, which is a notable gap given the cost disclosure.

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 operation and then the cost, return, and async facts. Each sentence is compact and there is no padding, though the opening line largely duplicates the title rather than adding information.

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 17-parameter tool with deep nesting and no output schema, the description does state that Adobe output URLs are returned and mentions the async option, which is helpful. However, it gives no guidance on how to handle the async path (e.g., polling via get_job_status), no mention of the confirm requirement, and no direction on choosing between the many compatibility aliases.

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 94%, so the schema already documents nearly every parameter, including aliases, domain restrictions, and the confirm flag. The description adds no parameter-level meaning beyond what the schema provides, making the baseline of 3 appropriate.

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 first sentence, 'Generate object composite,' is essentially the tool title restated, giving a clear verb+resource but no information that separates it from close siblings like adaptive_composite and precise_composite. The remaining sentences describe cost and return format rather than purpose, so an agent cannot tell from the description alone what this composite operation actually does with the inputs.

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?

There is no when-to-use guidance and no explicit comparison against alternatives such as adaptive_composite, precise_composite, or generative_fill, despite several overlapping siblings. The only conditional hint is 'Set wait=false to return an async job,' which is an invocation detail rather than tool-selection guidance.

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