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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the {source, id} row shape that plugs into references, the presence of durationSeconds on audio rows, and the hard 15s cap Seedance enforces on reference audio — a real behavioral constraint not in any structured field.

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, all front-loaded with the scope first, then the return shape, then filters. Dense but every clause carries a distinct fact; only the phrase 'besides actors' sits slightly awkwardly relative to the opening scope statement.

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 no output schema, the description does carry the burden of explaining returns, and it delivers the row shape, the source/id semantics, and the audio duration field. It omits pagination/limit behavior and result ordering, which are the remaining gaps for a list 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 only 33% — q is documented but limit is not, and mediaType is only constrained by enum. The description compensates partially by restating the mediaType values and framing q as a name search, but says nothing about limit or pagination behavior. Baseline 3 is appropriate given the partial coverage.

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 (List) and resource (the SeedDance reference library) and explicitly scopes what it contains: uploads, AI generations, main-Studio outputs, and admin-curated assets. It also names the one thing it excludes — actors — which routes the agent to the sibling list_seedance_actors 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?

The description makes the use case explicit: assembling the references param for seedance_generate_video, and it distinguishes itself from the actor list. It gives filtering guidance (mediaType or name search) but does not state when-not to use it or what happens on an empty result.

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