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

No annotations are provided, so the description carries the behavioral disclosure burden. It does add a Returns clause mentioning task ID, video URLs, and metadata, which hints at task-based behavior. However, it omits important operational traits such as generation taking significant time and the likely need to poll or wait for the final video.

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 compact and front-loaded: action, use cases, alternative, and return summary come in a readable order. The 'simplest way / high-quality' sentence is slightly promotional and redundant with the first sentence, but it does not meaningfully inflate the length.

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, the input schema covers most details and an output schema presumably documents return structure. The description covers primary use cases and sibling routing, but it does not explain how to retrieve the final result, e.g., via seedance_get_task, or warn about long-running generation. It is adequate but has clear 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%, and the schema already documents all 17 parameters with defaults, enums, and model-specific constraints. The description adds little beyond identifying the prompt as the core input and clarifying this is the text-only variant, so the parameter burden is adequately carried by the schema.

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 AI video from a text prompt using ByteDance Seedance.' It also names the sibling seedance_generate_video_from_image, so an agent can immediately distinguish text-to-video generation from image-conditioned generation.

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' bullets clearly define the conditions: creating video from text, no reference images, and quick text-to-video generation. It explicitly directs image-reference workflows to seedance_generate_video_from_image instead, which is excellent 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 behavioral disclosure burden. It discloses the mutual exclusivity constraint between reference images and frame URLs, and notes that at least one image must be provided. It also states the return value (task ID and video info). Though it doesn't detail async behavior or polling requirements, this is reasonable coverage for a generation 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 well-organized with a lead sentence, usage bullets, a constraint note, and a returns section. It is slightly longer than strictly necessary but every section adds value, and the most critical constraint is called out explicitly near the end of the main text.

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 21 parameters and no annotations, the description does a good job capturing the essential behavioral context: image input modes, mutual exclusivity, and required input. The return-value section is present, and the schema covers parameter details. Minor omissions like asynchronous/polling behavior are not fatal because the output schema provides return structure.

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 already explains every parameter. The description adds meaning by grouping input modes (first frame, last frame, reference images) and highlighting the interaction constraint among them. It doesn't restate each parameter but adds selection-level semantics that the flat schema lacks.

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 that this tool generates AI video from reference images using ByteDance Seedance, distinguishing it from the sibling seedance_generate_video (which presumably lacks image control). It explicitly names the input modes (first frame, last frame, reference images) and supports this with concrete usage cases.

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 when-to-use bullet points and a critical exclusion rule: reference_image_urls cannot be combined with first_frame_url/last_frame_url. It also mandates at least one image input. This is strong guidance for tool selection and correct invocation.

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, but description covers task statuses and error handling. Read-only nature implied, but no mention of auth or rate limits; adequate for simplicity.

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?

Efficient use of bullet points for statuses and returns. Front-loaded key purpose, 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?

Given output schema exists and tool is simple, description covers all necessary context: statuses, return content, and usage rationale.

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 100% with parameter description. Description adds value by specifying source of task_id (from generation response).

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?

Specific verb 'Query' and resource 'status and result of a video generation task'. Clearly distinguishes from sibling generation and list tools.

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?

Explicit usage scenarios (check completion, retrieve URLs, get details). No explicit when-not, but context is clear for a query tool.

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, but description implies a safe read operation by calling it a query. Mentions batch limit in schema, which adds practical info. Could explicitly state read-only nature.

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, front-loaded with purpose, then usage guidelines, then returns. Every sentence adds value with no fluff.

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?

Tool has a simple interface (1 param, output schema exists). Description covers all necessary aspects: purpose, usage context, and return summary. Minor gap: no explicit safety statement.

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 covers parameter semantics fully (100% coverage) with description of task_ids and batch limit. Main description adds only context about batching and returns, but no extra parameter meaning beyond schema.

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 video generation tasks at once' and distinguishes itself from sibling tool `seedance_get_task` by emphasizing batching efficiency.

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 when to use the tool with bullet points and compares to the sibling tool, stating 'More efficient than calling seedance_get_task multiple times'.

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?

Clearly describes the operation as a listing of actions/tools returning a categorized list, which is transparent for a read-only operation; no annotations provided.

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 three-sentence description front-loads the purpose and return value, with no unnecessary 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?

Given zero parameters and presence of an output schema, the description adequately covers purpose, output, and utility without 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?

No parameters, but description adds meaningful context about the return value (categorized list of actions and tools) beyond the empty schema.

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?

Clearly states it lists all Seedance API actions and corresponding tools, distinguishing it from sibling tools that generate videos, get tasks, or 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?

Implied use as a reference guide for understanding capabilities, but no explicit when-to-use or when-not-to-use guidance compared to alternatives.

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 discloses that the tool lists models with capabilities and pricing, implying a read-only operation with no side effects. This is adequate for a simple list 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 three sentences, each contributing to the purpose, usage, and return value. It is concise without being overly terse, though some minor redundancy exists ('Shows all available model options' repeats the first sentence).

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 the existence of an output schema, the description adequately covers the tool's purpose, usage, and return value. No further information is needed.

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 zero parameters, and schema coverage is 100%. The baseline for 0 parameters is 4. The description does not need to add parameter information.

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 'List all available Seedance models with their capabilities and pricing.' This is a specific verb+resource combination that distinguishes it from sibling tools like seedance_generate_video or seedance_get_task.

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 'Use this to understand which model to choose for your video generation,' providing clear context for when to use the tool. It does not explicitly state when not to use alternatives, but the purpose is simple enough.

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, the description transparently states it returns tables of resolutions and aspect ratios with descriptions. It adds value beyond a simple 'list' by mentioning use cases and descriptions, though it does not detail freshness or caching behavior.

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 two sentences and a 'Returns:' clause. Every sentence adds value, and the structure is front-loaded with the primary action.

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, the description fully covers what the tool does and returns. It is complete for a simple listing 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?

No parameters exist, and schema description coverage is 100%. Per baseline, score 4 is appropriate as the description does not need to add parameter info.

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 explicitly states the tool lists all available resolutions and aspect ratios for Seedance. It clearly distinguishes itself from sibling tools like seedance_list_models or seedance_list_actions by focusing on resolution options.

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 implies usage context (before generating a video) but provides no explicit when/when-not guidance or alternatives. The agent can infer use, but lacks explicit direction.

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