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

No annotations provided, so description carries the full burden. It discloses the underlying HTTP method (DELETE), the fact that only queued tasks can truly be cancelled, that calls on running tasks fail, and the post-cancellation purge delay. It does not cover idempotency or behavior when task_id does not exist, but the output schema likely handles error responses. Overall, good transparency for a simple cancellation 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?

Three sentences total. First sentence immediately states the dual purpose. Second sentence explains the key behavioral limitation. Third sentence adds lifecycle context. No wasted words, front-loaded with essential 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 tool with one required parameter and clear cancellation semantics, the description covers the operation's dual nature, failure cases for running tasks, and post-cancellation cleanup. An output schema exists (though not shown), so return value explanation is not needed. The description is complete for the complexity level.

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 input schema has 100% description coverage—task_id is described as 'Task ID to cancel or delete.' The tool description does not add any additional semantics (e.g., format, source, or validation). Since the schema already provides the meaning, the description offers no extra value, meeting 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 clearly states it cancels queued tasks or deletes finished records, using the verb 'cancel or delete' and the resource 'Seedance task'. It distinguishes between the two states, providing specific scope. The sibling tools (create, get, wait, download, list) further clarify this is the cancellation tool.

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 says when to use: for queued tasks (cancel) or finished ones (delete). Provides a critical caveat that running tasks cannot be stopped and the call will fail. Mentions that cancelled tasks are purged after 24 hours. Lacks explicit alternatives (e.g., no mention of what to do if you need to stop a running task), but the tool set doesn't include such an option, so the guidance is adequate.

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?

Without any annotations provided, the description carries full burden and does well: declares asynchronous gen, delays minutes, returns task ID immediately. It explains that BytePlus rejects mixed input shapes, details media upload rules (local images inlined, local videos not supported), and notes model-specific behaviors (Seedance 2.5 doesn't support seed/camera_fixed). Minor gap: doesn't describe error behavior if a reference is invalid.

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?

Description is well-structured with clear sections: async behavior first, then three input shapes, then media constraints, then parameter notes. It front-loads the most critical info (async return, sibling tool guidance). It is somewhat long but every sentence earns its place for a complex tool with 18 parameters. Could be slightly tighter by combining repeated mentions of model version constraints.

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 high-complexity tool with 18 parameters and no annotations, the description covers all essential aspects: the three input shapes and mutual exclusivity, the async behavior, sibling tool workflow, media upload rules per type, model-specific limitations (Seedance 2.5 param constraints, max counts), citation syntax, and special parameters (return_last_frame chaining). The output schema exists, so return values are covered separately.

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 baseline is 3; the description adds significant value by grouping parameters into three mutually exclusive shapes, explaining relationships (first_frame mutually exclusive with *_references), detailing citation syntax (@Image 1, @Video 2), specifying upload constraints per parameter type, and clarifying model-specific constraints (seed, camera_fixed not for 2.5). Some schema descriptions already include individual parameter details, but the description's structural insight exceeds schema alone.

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 starts a Seedance video generation task, returns a task ID, and explicitly distinguishes the asynchronous nature from sibling tools like seedance_wait_for_video. It precisely describes three input shapes (text-to-video, image-to-video, omni reference-to-video) with exact parameter combinations, making it unambiguous what the 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 guidance on when to use this tool vs. alternatives: states it is asynchronous and returns immediately, then instructs agents to follow with seedance_wait_for_video (when user wants video) or seedance_get_video (single check). It also explains that media fields have different constraints (local images vs. public URLs for videos), which directly affects tool selection and parameter setup.

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 fully carries the burden. It discloses critical behaviors: output URLs expire after 24 hours and allow only 100 downloads (no reissue), the tool looks up the current URL itself, file is written to current directory if no path given, existing files are never overwritten unless overwrite=true, and include_last_frame requires the task to have been created with return_last_frame.

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 about 100 words, well-structured with the primary purpose first, followed by usage context and parameter details. Every sentence adds value, no redundancy or 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 the 4 parameters and full schema coverage, the description is complete. It explains prerequisites (task must be succeeded, within 24h), file handling rules, optional behavior (include_last_frame condition), and the self-service nature of URL resolution. An output schema exists but the description correctly focuses on usage context rather than return format.

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%, giving a baseline of 3. The description adds value beyond the schema by explaining that output_path defaults to current directory for <task_id>.mp4, that existing files are never overwritten without explicit overwrite=true, and that include_last_frame requires the original task to have return_last_frame. These details clarify default behavior and preconditions not obvious from parameter descriptions alone.

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 the tool saves a finished Seedance video to a local file, with the specific verb 'Save' and resource 'finished Seedance video'. It distinguishes from siblings like seedance_get_video (just view link) by explaining when to use it for permanent storage rather than just seeing a link.

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 explicitly says to use this when the user wants to keep the video rather than just a link, and mentions URL expiration and download limits. It also states the task must be in 'succeeded' state. While it doesn't explicitly name alternative tools, the context of sibling names and the 'use this whenever' phrasing provides clear 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?

Although no annotations are provided, the description fully discloses the tool's behavior: it performs a single check, returns current state, and lists all possible statuses. It details the result structure (on success: video_url with 24h validity, resolution, aspect ratio, duration, frame rate; on failure: error_code and error_message). It also mentions task retention policy (7 days). The only minor gap is no explicit mention of whether it's a mutation or read-only operation, but the context strongly implies a safe read.

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 earning its place: the first states the core purpose, the second provides usage guidance and an alternative, and the third details the response format and lifecycle. No fluff, perfectly front-loaded.

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 low complexity (1 parameter, all required, no enums, 100% schema coverage), the tool is simple. The description covers the input (task_id), behavior (single poll, no looping), output (with detailed success/failure fields, plus video URL validity), and retention policy. An output schema exists, but the description still summarizes the key fields, which is helpful. No gaps remain for an agent to misinterpret.

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% (the only parameter task_id has a clear description in the schema). The description adds limited additional semantic value beyond the schema, as the schema already explains it's the task ID from seedance_create_video with an example format. However, the description could have elaborated on how to obtain the task_id, but it's mostly sufficient.

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 'Check a Seedance generation task once and return its current state.' It specifies the verb (check), resource (Seedance generation task), and action scope (once). The tool is well-differentiated from siblings like seedance_wait_for_video, which is explicitly mentioned as the alternative for polling.

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 explicitly tells when to use this tool ('quick status poll') and when not to ('if the user is waiting for the finished video, use seedance_wait_for_video instead of calling this in a loop'). It provides clear guidance on avoiding loops, which is critical for agent behavior.

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 full burden for behavioral disclosure. It clearly states the tool is read-only (listing tasks), notes the data retention period (7 days), and explains that finished tasks' video URLs are only fetchable within 24 hours. The only gap is that it doesn't explicitly mention it's non-destructive, but the listing action implies this.

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 long and front-loaded with the core purpose. The first sentence states action, scope, ordering, and optional filters. The second provides concrete use cases. The third covers data retention. Every sentence serves a distinct informative purpose with no repetition or 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 the tool has no required parameters, a fully described schema (4 params, 100% coverage), an output schema (not shown but present), and clear behavioral context (retention, ordering, use cases), the description leaves no critical gaps. It is complete for an agent to decide when and how to invoke the 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 coverage is 100% and each parameter's description is clear (model ID/endpoint ID filtering, status enum, page number/page size with bounds). The description adds context by noting common use cases (filter by status, model) but does not elaborate beyond what the schema provides. Since coverage is high, baseline 3 is appropriate, and the additional context bumps it to 4.

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 specifies the action ('List recent Seedance generation tasks'), the scope ('for this account'), ordering ('newest first'), and optional filtering by status or model. It also explicitly distinguishes the tool from siblings like seedance_create_video or seedance_get_video by focusing on listing tasks rather than creating or retrieving individual videos.

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 guidance on when to use this tool: to recover a lost task ID, check queued tasks, or re-fetch a video URL within 24 hours. It also mentions the retention policy (7 days), setting clear boundaries on expected results. No sibling tool duplicates this list behavior, so exclusion criteria are implied.

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 covers key behaviors: polling with automatic backoff, timeout behavior (doesn't cancel), typical time estimates, and return of final result including video URL. It does not mention rate limits or auth requirements, but for a polling tool this is reasonable. The description adds value beyond what structured metadata could 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?

The description is three sentences long, each earning its place: the first states the core action, the second specifies when to use it, and the third provides critical usage guidance. It is front-loaded with the most important information and contains no filler or redundant phrases.

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?

The description covers the main purpose, usage context, timeout behavior, and auto-backoff. An output schema exists, so return value details are handled there. However, it does not explicitly differentiate from 'seedance_get_video' (if that tool exists for non-polling status checks). Given the tool's polling nature and the presence of other sibling tools, the description is nearly complete.

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 input schema has 100% description coverage, so each parameter already has a clear explanation. The description adds some context (e.g., 'task ID from seedance_create_video', timing guidance for timeout_seconds) but does not significantly enhance understanding of parameters beyond what the schema provides. Baseline of 3 is appropriate since the schema does most of the work.

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 the tool polls a Seedance task until completion or timeout and returns the final result including the video URL. It explicitly differentiates from siblings by specifying when to call it: 'right after seedance_create_video whenever the user wants the finished video rather than a task ID.' The title also reinforces the purpose.

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 guidance on when to use the tool ('Call this right after seedance_create_video...') and includes practical advice about adjusting timeout for longer jobs. It also clarifies that a timeout does not cancel the task and that the task can be waited on again. However, it does not explicitly state when not to use it or mention alternative sibling tools for different use cases.

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