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

With no annotations, the description carries the full burden. It usefully discloses the output structure (base image plus up to 16 transparent layers), but it does not disclose side effects or caveats such as async task behavior, default watermarking, non-destructiveness, or cost/rate implications.

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?

One sentence contains a verb, object, and output shape with no filler. The key information is front-loaded, and every word earns its place.

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 six-parameter tool with an output schema and no annotations, the description is serviceable but incomplete: it omits the asynchronous/deferred result path implied by callback_url and the need to poll via seedream_get_task, and it does not address watermark or task lifecycle behavior. However, the input schema is thorough and the output schema is present, closing some gaps.

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 input schema already documents all six parameters and the enum. The top-level description adds no parameter-level meaning beyond the schema, which matches the baseline of 3.

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 uses a specific verb ('Decompose') with a clear resource and outcome: one input image becomes a base image plus up to 16 editable transparent layers. This distinguishes it from sibling tools like seedream_edit_image or seedream_generate_image even without explicitly naming them.

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 intended use is implied by the verb and the layer output, but the description does not explicitly state when an agent should choose decompose over edit_image, nor does it mention exclusions or prerequisites. Sibling tool names provide some context, but the description itself gives no direct routing guidance.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool modifies images, supports single or multiple inputs, and returns a JSON payload with task_id, trace_id, success status, and image URLs, implying an async pattern. It also gives realistic transformation examples that help set expectations, though it doesn't touch on topics like rate limits, authentication, or failure modes.

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 clear sections (overview, 'Use this when', common use cases, returns) and bullet lists that improve scannability. There is some minor redundancy between the opening line and the second paragraph—both state that the tool modifies existing images—but overall it is appropriately sized for a 13-parameter tool and front-loads the core purpose.

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 13 parameters and no annotations, the description provides a solid foundation: it names the operation, gives rich usage context, lists example prompts, and describes the return payload. The 100% schema coverage handles parameter details, and the output schema exists, so return values are already structured. It is not missing critical information, though an explicit pointer to seedream_generate_image for text-to-image would be a small enhancement.

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 baseline is 3; the schema already documents all 13 parameters well. The description adds prompt examples and use cases that indirectly inform the prompt parameter, but it doesn't add meaning beyond the schema for parameters like watermark, output_format, or sequential_image_generation. It is neither redundant nor absent, but it doesn't elevate beyond the schema's own documentation.

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 opens with a specific verb and resource: 'Edit or modify existing images using ByteDance's Seedream/SeedEdit model.' It clearly distinguishes itself from the sibling seedream_generate_image by repeatedly emphasizing existing images rather than generation from scratch. The scope is further clarified through concrete examples like style transfer, background change, and virtual try-on.

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' section provides clear contexts: modifying/transforming existing images, changing style/background/colors, applying artistic transformations, virtual try-on, and scene composition. It does not explicitly mention alternatives or when-not-to-use, but the conditions are concrete enough that an agent can route correctly. A minor gap is the lack of an explicit exclusion to seedream_generate_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?

With no annotations present, the description carries the behavioral burden, and it does disclose the return shape (task_id, trace_id, success status, image data/URLs) and broad model capability differences. However, it does not clarify that generation may be asynchronous and require polling via get_task, and its 'including image URLs' statement is incomplete for the b64_json response format. These are notable gaps for a complex generation tool, though not contradictions.

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 clear headings, front-loaded purpose, and scannable bullets for use cases and model selection. It is somewhat long, and the model guide partially repeats schema content, but each section contributes actionable guidance. No filler or vague jargon detracts from the structure.

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?

Given 11 parameters and model-specific compatibility constraints, the description covers core use cases and return values, and the output schema fills in return-structure details. Yet it misses the Pro model variant in the guide, does not mention polling via seedream_get_task, and does not summarize model-feature incompatibilities (e.g., Pro lacks sequential generation and web search). These gaps leave an agent less prepared for advanced but valid invocations.

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. The description adds a useful high-level model selection heuristic, but it largely duplicates the schema's model parameter details and omits the Pro model from its guide. It provides no additional meaning for size, tools, watermark, callback_url, output_format, or response_format beyond what the schema already explains.

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 opens with a specific verb and resource: 'Generate an AI image from a text prompt using ByteDance's Seedream model.' It explicitly distinguishes itself from seedream_edit_image by stating 'Do NOT use this when ... use seedream_edit_image instead,' and the sibling list confirms it is the generation vs. editing/list/getting task tool. No ambiguity remains about what this tool does.

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 description provides explicit 'Use this when' and 'Do NOT use this when' sections, including direct alternatives for editing or combining images. It also adds a model selection guide with quality/value heuristics, giving an agent concrete decision criteria for invocation. This goes beyond any structured schema data.

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?

Discloses it returns status and image information, implying a read-only operation. With no annotations, the description carries the burden and does well, though it could explicitly state it is non-destructive.

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?

Concisely structured with bulleted usage scenarios and a return summary, though some minor repetition between the first line and the list.

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 an output schema present and a single required parameter, the description fully covers the tool's purpose and usage, leaving no gaps.

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% and the description's parameter info duplicates the schema description, adding no new meaning beyond what the schema provides.

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 clearly states it queries the status and result of a specific task, distinguishing it from sibling tools like seedream_generate_image and seedream_get_tasks_batch.

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 cases (checking completion, retrieving URLs, getting full details) but does not mention when not to use or compare to seedream_get_tasks_batch.

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?

No annotations provided, so description carries full burden. It describes the operation as querying (read-only) and states it returns 'Status and image information'. It does not mention auth requirements or rate limits, but for a query tool, this is sufficient. Slightly more detail on the response format would improve, but overall transparent.

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 concise with a clear initial sentence, a bullet-style list for usage scenarios, and a returns section. No redundant information; every sentence adds value.

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?

Given the simplicity (1 parameter, no annotations, output schema exists), the description sufficiently covers purpose, usage, and returns. It doesn't explain output schema details, but that's acceptable as the schema itself is present. A hint about pagination or result format could improve, but not necessary.

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% with a clear parameter description. The tool description adds context about efficiency and use cases but does not add new parameter semantics beyond what the schema provides. Baseline 3 is 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 description clearly states 'Query multiple Seedream image tasks at once' and distinguishes from the sibling tool 'seedream_get_task' by highlighting batch efficiency. The verb 'query' and resource 'tasks' are specific.

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 when-to-use scenarios: 'when you have multiple pending generations', 'when you want to get status of several images at once', 'when tracking a batch'. Although not explicitly stating when not to use, it implies the alternative for single tasks (seedream_get_task).

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?

No annotations provided, so description carries full burden. It states it returns a formatted table with descriptions, implying no side effects. Does not mention authentication requirements or data freshness, but for a read-only listing tool it is adequately transparent.

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?

Concise: one line for purpose, bulleted use cases, and output format. No fluff. Well-structured and easy to scan.

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?

Given zero parameters and an output schema exists, description is complete. Explains what models are listed and for what purpose. Does not need to explain return values since output schema covers that.

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?

No parameters in input schema. Description compensates by detailing what the output includes (capabilities, pricing, descriptions). Baseline 4 for zero-param tools where description adds meaningful output context.

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?

Description clearly states it lists all available Seedream models with capabilities and pricing. Specific verb 'list' and resource 'models'. Distinguishes from sibling tools which focus on editing, generating, or retrieving tasks.

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?

Explicitly lists three use cases: user asks about models, need to choose a model, want to compare capabilities. Does not mention when not to use, but that is not critical for a simple listing tool. No alternative tools suggested, but sibling tools are distinct in purpose.

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?

No annotations are provided, so the description carries the full burden. It states it returns a 'formatted list of all size options with descriptions', which is sufficient for a simple read-only listing tool with no parameters. It does not disclose potential rate limits or side effects, but these are minimal for such a tool.

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 concise, with a clear 'Use this when' section and a 'Returns' section. Every sentence adds value, and the structure is front-loaded with the core purpose.

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?

Given the tool has zero parameters and a simple list output, the description fully covers its purpose, usage context, and return value. The output schema exists, and the description notes the return format adequately.

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 has no parameters, and schema description coverage is 100%. Per guidelines, baseline is 3 when coverage is high. The description does not add any parameter semantics since there are none to explain.

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 uses a specific verb 'List' and resource 'image sizes and resolution options for Seedream'. It clearly distinguishes from sibling tools like seedream_generate_image and seedream_list_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 description includes a 'Use this when' section listing three clear scenarios. While it doesn't explicitly state when not to use it or mention alternatives, the guidelines are adequate for an agent to understand when to invoke this tool.

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