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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, non-idempotent, openWorld), so safety is covered. The description adds the layer-count ceiling ('up to 16'), but omits that this is an async job (callback_url param, get_task/get_tasks_batch siblings) and says nothing about cost, latency, or whether the source image is retained.

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?

A single tight sentence that front-loads the verb and resource and still conveys the output cardinality. No filler.

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?

An output schema exists, so return values need not be re-explained, and the schema itself covers all parameters. However, for a destructive, open-world, non-idempotent async generation tool, the description omits how results are delivered and whether the operation is reversible, leaving a real gap for an agent deciding whether to call it.

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 all six parameters are already documented in the schema. The description adds the decomposition result structure but no parameter syntax or default behavior, so the baseline 3 applies.

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 ('Decompose') plus the resource ('one image') and goes further by describing the output shape: a base image and up to 16 editable transparent layers. That distinguishes it from seedream_generate_image and seedream_edit_image on capability, though it never names those siblings explicitly.

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, no statement of when to prefer decompose over edit or generate, and no prerequisites (supported input types, async expectations). The reader must infer usage from the verb alone.

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

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

Annotations already disclose the safety profile (destructiveHint=true, openWorldHint=true, non-idempotent), so the description's job is lighter. It implies async behavior via 'task_id' and mentions callback_url only in the schema, but never explains the polling workflow or that results may need seedream_get_task. Adds some context, but much of the return-value text duplicates the existing output schema.

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?

Purpose is front-loaded in the first sentence, which is good, but the body is padded: the 'Use this when' bullets and the 'Common use cases' bullets substantially overlap (both cover style, background, attributes, try-on), duplicating the same information twice. The Returns section is also largely redundant given a defined output 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?

For a 13-parameter tool with 100% schema coverage, an output schema, and full annotations, the description covers purpose, use cases, and return shape adequately. It could say more about the async/task_id workflow and the multi-image semantics of 'image', but nothing essential is missing.

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 the schema carries all parameter detail (size, model, watermark, background, output_format, etc.) and the baseline is 3. The description only adds prompt examples, which mirror the schema's own prompt description rather than extending it.

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+resource ('Edit or modify existing images') and names the underlying model family. The emphasis on 'existing images' cleanly distinguishes it from the sibling seedream_generate_image, and the modification scope (style, background, attributes, clothing) is stated explicitly.

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 an explicit 'Use this when' list plus concrete use cases (style transfer, background change, virtual try-on), which gives strong positive guidance. However, it never names alternatives or states when NOT to use it — e.g., that creating a brand-new image should go to seedream_generate_image, or that decomposition goes to seedream_decompose_image.

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

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

Annotations cover safety profile (destructiveHint=true, openWorldHint=true, non-idempotent), and the description adds useful context beyond them: model capability differences (streaming/web search/sequential generation availability) and the returned task_id/trace_id plus image URLs. It doesn't address cost, latency, or async timing, but it already exceeds the annotation baseline.

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 purpose statement followed by clearly labeled sections that an agent can scan quickly. The trailing 'Returns:' block is largely redundant given an output schema exists, which is the only minor inefficiency.

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 an 11-parameter generation tool with full schema coverage, existing annotations, and an output schema, the description supplies the missing routing logic (generate vs. edit) and model-selection context. The agent has everything needed to choose and invoke 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%, so the schema already documents all 11 parameters, including the model enum variants. The description's 'Model selection guide' largely restates the schema's model descriptions verbatim and adds no guidance on size, tools, watermark, or callback_url, so it does not go beyond structured data.

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?

Opens with a specific verb+resource ('Generate an AI image from a text prompt') and names the underlying model family. It explicitly distinguishes itself from sibling tools (seedream_edit_image) for editing/combining, so an agent can route without opening another 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?

Provides explicit 'Use this when' and 'Do NOT use this when' blocks, and names the alternative tool (seedream_edit_image) for both excluded cases. This is a textbook when/when-not/alternative structure.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered without description help. The description adds the polling intent ('check if a generation/edit is complete'), which is genuine behavioral context, but omits rate limits, auth requirements, or expected latency for an async task lookup.

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 purpose sentence and its scoping are front-loaded, and the content is short enough to scan quickly. The 'Use this when' bullets and the Returns block are partly redundant with the opening paragraph and the existing output schema, which costs a little density.

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 one fully documented required parameter, a present output schema, and covering annotations, the definition gives an agent everything needed to invoke it correctly. The main missing piece is lifecycle guidance (polling cadence / whether status can be mid-flight), which matters for an async task tool.

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%, and the task_id description already explains it comes from the generate/edit responses. The tool description adds no further meaning about the parameter, so the baseline 3 for full schema coverage applies.

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: 'Query the status and result of a Seedream image generation or edit task,' which an agent can immediately distinguish from the generate/edit siblings. It stops short of differentiating itself from seedream_get_tasks_batch, so the single-vs-batch boundary must be inferred from the name.

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 an explicit 'Use this when:' block with three concrete conditions (check completion, retrieve URLs, get full details), which is clear situational guidance. It names no exclusions or alternatives, notably omitting when to prefer seedream_get_tasks_batch, and the three bullets restate largely the same trigger.

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

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

The annotations already declare the operation as read-only, idempotent, open-world, and non-destructive, so the safety profile is well covered. The description adds that results include status and image information for all queried tasks, but does not disclose batch-size limits, partial-failure behavior, or how unknown task IDs are handled.

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 purpose is front-loaded and the bullet structure is easy to scan. There is mild redundancy between the opening sentence, the efficiency sentence, and the bullet items, and the 'Returns' section duplicates information available via the output schema, but none of it is confusing.

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 simple one-parameter batch read with an output schema and rich annotations, the description covers purpose, usage, alternative, and return content adequately. It stops short of addressing practical edge cases such as maximum batch size or mixed valid/invalid task IDs.

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%, and the schema already documents task_ids as a list of task IDs supporting multiple tasks. The description adds no syntax, format, or ordering constraints beyond what the schema provides, so the baseline of 3 applies.

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 ('Query multiple Seedream image tasks') and explicitly positions itself against the sibling single-task tool by saying it is 'More efficient than calling seedream_get_task multiple times.' An agent can distinguish this from seedream_get_task without opening either 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?

Provides an explicit 'Use this when' list covering pending generations, checking several images at once, and tracking a batch. It also names the alternative (seedream_get_task) and the condition under which this tool is preferable, leaving no routing ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only addition is the return shape (a formatted table), which partly duplicates the output schema and says nothing about caching, rate limits, or ordering.

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?

Purpose sentence is front-loaded and the bullets are scannable and short. The trailing 'Returns' block is largely redundant given an output schema exists, so the text is not maximally economical.

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 zero-parameter, read-only catalog call with an output schema and full annotation coverage, the description supplies everything an agent needs to decide to call it. The only shortfall is not stating that results are exhaustive/static, which would help an agent avoid redundant 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?

The tool takes no parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No misleading parameter language is present.

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+resource ('List all available Seedream models') and enumerates the payload (capabilities and pricing), which cleanly separates it from the generate/edit/decompose siblings.

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?

Three explicit 'use this when' bullets give clear triggering conditions (user asks what's available, model selection help, capability comparison). It does not name an alternative sibling or state when not to use it, but for a zero-arg catalog tool the alternatives are obvious.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description's only behavioral addition is the 'Returns: Formatted list...' line, which largely duplicates the existing output schema. Adequate but not additive.

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 purpose, which is good, but the three 'Use this when' bullets are near-synonyms of one another and the 'Returns' section restates the output schema. Roughly a third of the text could be cut without loss of signal.

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 zero-parameter, read-only listing tool with a full output schema and complete annotations, the description covers purpose, timing, and return shape. Nothing essential is missing, though it adds little that the structured fields do not already supply.

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?

The tool takes zero parameters, so there is no parameter semantics to document; baseline is 4. The empty schema is self-explanatory and the description correctly does not invent arguments.

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: 'List all available image sizes and resolution options for Seedream.' This is unmistakably distinct from siblings like seedream_generate_image or seedream_get_task. It stops short of naming seedream_list_models as the nearest-lookalike sibling, so an agent must infer the split between 'sizes' and 'models'.

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?

The 'Use this when:' block gives three concrete invocation conditions (user asks about sizes, agent needs to choose resolution, agent wants to understand options). That is real when-to-use guidance, but there are no exclusions or named alternatives, so it falls short of a 5.

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