AnimGen

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

Beyond destructive/idempotent annotations it discloses the material consequences an agent cannot guess: credits already charged are not refunded, in-production work may not stop, and specific providers reject cancellation with GENERATION_ALREADY_SUBMITTED. The V1 MiniMax remote-confirmation caveat is exactly the kind of non-obvious behavior that prevents misuse.

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 action is front-loaded in sentence one, followed by only decision-relevant caveats about rejection, confirmation, and refunds. It is dense with provider names but no sentence is filler; slight compression would improve scanning.

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, return fields need not be explained, and the description covers the remaining unknowns: preconditions, provider-specific failure modes, and the financial irreversibility of the call. Nothing needed to invoke it correctly 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 coverage is 100% and the single animation_id is already documented as the owned task the user asked to cancel. The description adds no further syntax or semantics for the parameter, 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?

The first sentence states a specific verb and resource ("Cancel an owned animation"), which lets an agent separate it from cancel_video_generation and cancel_animation_export by resource scope. It never names those siblings explicitly, so differentiation relies on inference from the noun.

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?

It gives concrete preconditions ("Inspect cancellation_allowed and cancellation_reason") and a fallback rule for uncertain cases ("keep polling the original task even if cancellation is uncertain"). What's missing is explicit routing guidance versus the sibling cancel_* tools.

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 destructiveHint=true and idempotentHint=true; the description adds genuinely useful context beyond them: cancellation preserves the source video for a later export (bounding the blast radius of the 'destructive' hint) and an ownership constraint. The 'continue polling until a terminal state' instruction also tells the caller what to do next, which is not derivable from the annotations.

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?

Two short sentences with the scoping constraint front-loaded and no filler. The polling instruction is slightly abrupt about what to poll (presumably get_animation_export), but the sentence still 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?

An output schema exists, so return values need not be described, and the description covers ownership, retention of the source asset, and post-cancel polling behavior. The only real omission is identifying what task_id refers to and which tool to poll with.

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 single task_id parameter has 0% schema description coverage, and the description never mentions it at all. The name and uuid format make its meaning mostly inferable, but the description does not clarify whether it is the export task id or the animation id — a real ambiguity worth documenting.

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 (cancel) and resource (an owned animation export), and the word 'export' naturally separates it from cancel_animation and cancel_video_generation. It does not explicitly name those siblings, so the differentiation is implied by vocabulary rather than spelled out.

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?

'Cancel an owned export only' implies an ownership precondition and narrows applicability, but there is no explicit when-to-use/when-not framing against cancel_animation or cancel_video_generation. The agent must infer the choice from the resource name 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?

Beyond the annotations, the description discloses important behavior: inspect cancellation_allowed and cancellation_reason, model-specific rejection codes, remote confirmation for certain queued tasks, continued polling after uncertain cancellation, and no refund guarantee. These details materially inform how an agent should interpret and handle cancellation outcomes.

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 front-loaded with the core action, followed by inspection guidance, model-specific constraints, and post-cancellation behavior. Every sentence carries operational value with 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 the presence of annotations and an output schema, the description supplies the key behavioral context needed to invoke and reason about cancellation. It covers eligibility checks, model-specific exceptions, polling behavior, and refund caveats.

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?

There is one required parameter, task_id, but schema description coverage is 0%. The description implies an owned source-video task but does not explain task_id semantics, where to obtain it, or how it relates to sibling tools. The type and UUID format in the schema do 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 states a specific verb and resource: 'Request cancellation of an owned source-video task.' This clearly distinguishes the operation from generation or retrieval, though it does not explicitly contrast with sibling tools such as cancel_animation or get_video_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?

It gives clear usage context and several when-not conditions, including model-specific rejection after submission starts and remote confirmation requirements for V1 MiniMax queued cancellations. It does not name an alternative sibling tool for checking task status, but the operational conditions are explicit.

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 indicate idempotentHint: true (calling multiple times safe) and destructiveHint: false (not destructive). The description adds the context that the upload must be 'prepared' and byte transfer completed, but does not state that validation is idempotent or clarify side effects. It doesn't contradict annotations, but also doesn't add much beyond them.

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 a single, concise sentence that gets straight to the point. It front-loads the primary action and result, with no unnecessary words.

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 single parameter, 100% schema coverage, and clear annotations, the description covers the essential context for calling this tool. It could mention the expected format of the return value (file_id), but the output schema is present and likely provides that. The prerequisite of 'prepared' is also stated.

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 already has 100% coverage, including a clear description of upload_id. The tool description adds no further parameter details. Since schema coverage is high, 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 states the specific action ('Validate a prepared image upload') and the key result ('return its reusable file_id'), which is clear and concise. It doesn't name sibling tools, but the verb 'complete' distinguishes it from 'prepare' in the sibling list.

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 that this tool should be used after preparation and byte transfer, as indicated by 'a prepared image upload'. However, it doesn't explicitly state when not to use it or mention alternatives. The required parameter description reinforces the prerequisite.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations by disclosing that the URL is 'short-lived' and signed, which informs the agent that the response is time-sensitive and requires no separate auth setup.

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 a single, efficient sentence with no filler. It front-loads the action and resource, and every word contributes to conveying what the tool does.

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 single-parameter, read-only tool with a rich parameter description and an output schema, the description is complete. An agent has sufficient information to invoke it correctly: asset_id, owned output asset scope, and the short-lived signed URL return behavior.

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 fully documents asset_id. The description adds little beyond the schema beyond reinforcing the 'owned output asset' scoping, which is also stated in the parameter description. 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 states a specific verb ('Return') and a clear resource ('metadata and a short-lived signed download URL for an owned output asset'). It distinguishes this tool from sibling get/quote/export tools by focusing on the download-specific behavior and the asset scope.

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 and schema context make the usage situation clear: this is for owned output assets, using an asset_id from task outputs rather than a task ID. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to know when to select it.

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 destructiveHint=true and idempotentHint=true; the description adds the crucial economic trait ('paid', approved credit cap) and the semantics that changing selection or FPS yields a new chargeable export rather than a re-render. It does not disclose whether the export is asynchronous or how failures/refunds behave, which matters for a destructive paid call.

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?

Two sentences, no filler, and the cost gate is front-loaded before the immutability caveat. Every clause carries 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?

Return values are covered by the output schema, so their absence is fine, but for a paid, destructive, asynchronous export fired against a nested request object, the description omits that the job is polled via get_animation_export and that it can be cancelled. Those workflow facts are not recoverable from the annotations or schema.

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?

With only 50% top-level schema coverage, the description compensates by explaining that quote_id must be approved and that max_credits is a cap, and by tying selection/FPS changes to new-export semantics. It stops short of stating whether quote_id and max_credits are mutually exclusive or which takes precedence, leaving the two alternative cost-control parameters partially ambiguous.

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 ('Start a paid export from an existing video asset') and explicitly distinguishes itself from the generation siblings by asserting it 'never regenerates source motion'. An agent can tell this apart from generate_animation and generate_video without opening any 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?

'with approved quote_id or max_credits' establishes the prerequisite gate for calling it, which is real usage guidance. However it never names the upstream/downstream siblings (quote_animation_export, get_animation_export, cancel_animation_export), so the agent must infer the quote-then-export-then-poll workflow rather than being routed to it.

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 destructiveHint=true and idempotentHint=true, but the description adds billing consequences the annotations cannot convey: credits 'may be charged once production begins', i.e. cost is incurred after a point of no return. That is meaningful context for a costly operation, though it omits how to observe completion (polling get_animation).

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, no filler, with the cost/payment signal placed first so an agent sees the risk before the parameter requirements. Everything in the description 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 destructive, paid, async operation with a fully described schema and an output schema, the description covers cost timing, preconditions, and idempotency. The one gap is that it doesn't say the result is retrieved later via get_animation, leaving the async workflow implicit.

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 quote_id, max_credits, idempotency_key and request are already documented in detail. The description restates the quote/max_credits either-or requirement and idempotency key presence but adds no syntax or format detail beyond the schema, so 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 and resource ('Start a paid asynchronous animation') with the cost and async traits front-loaded, which cleanly separates it from sibling generators like generate_video and from quote_animation/export_animation. An agent knows exactly what action this performs without opening the 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 precondition 'Requires a prior quote_id or an explicit max_credits limit and an idempotency key' effectively routes an agent to quote_animation first. It never names the sibling tool or states when not to use this one (e.g., use preview_video for a cheap check), so it stops short of full explicit alternatives 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?

Annotations already flag openWorld, idempotent, destructive, non-read-only, but the description adds what they cannot: the operation is PAID/credit-consuming, requires a pre-approved quote or cap, and is asynchronous. It does not explain failure/insufficient-credit behavior or what the destructive flag actually destroys, keeping it below a 5.

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?

Two sentences, both load-bearing: the first covers cost/gating, the second covers the async lifecycle. The critical cost precondition is front-loaded with zero 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 explained, and the description still supplies the lifecycle glue (task ID → get_video_generation → asset ID) that an agent needs to chain calls. What is missing is model-capability requirements (e.g. first_frame support) and the polling/retry contract for a long-running openWorld task.

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 50%, and the description clarifies the role of quote_id and max_credits ('approved', 'or') but leaves ambiguous whether both can be supplied and what happens if neither is. idempotency_key is left entirely to the schema, and the nested request object is not described beyond the schema's own rich field docs.

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 ('Start a paid video-only task') and the billing inputs that gate it ('approved quote_id or max_credits'). The 'video-only' qualifier implicitly separates it from generate_animation, though it never names that sibling directly.

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?

Gives the prerequisite (approved quote_id or max_credits) and outlines the follow-up flow (poll get_video_generation, retain asset ID). However it does not say when to prefer this over generate_animation, nor name quote_video_generation as the source of the quote, so the agent must infer the routing.

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 without the description. The description's added content is a list of returned fields, which duplicates what the existing output schema already conveys; no polling cadence, terminal-state, or error-handling behavior is disclosed.

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, front-loaded with the verb and resource, no filler. Nothing could be cut without losing content.

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 is complete about what data comes back, but since an output schema exists, those words are spent on redundant material while genuinely useful context (that this is the polling counterpart to generate_animation, and how it differs from get_animation_export) is absent.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains it is the 'Owned task ID returned by generate_animation'. The description adds nothing further about the ID's provenance or format, 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 ('Get') and resource ('animation') plus the exact facets returned: status, progress, credit state, errors, generated assets. That is well beyond a tautology. It does not, however, distinguish itself from the similarly named sibling get_animation_export, which an agent could easily confuse with this 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?

The description contains no when-to-use or when-not-to-use guidance and never mentions alternatives such as get_animation_export or the polling relationship to generate_animation. The only hint that this is a post-generation status check lives in the schema's animation_id description, not in the tool description itself.

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 establish that this is a read-only, idempotent, non-destructive operation, so the behavioral bar is lower. The description adds useful context beyond annotations: this polls an owned export task and can return resolved_export and outputs even after failure or cancellation, which is meaningful terminal-state 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?

A single compact sentence that front-loads the polling purpose and then adds the terminal-state inspection detail. Every clause earns its place 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?

Because an output schema exists, the description need not explain return fields, and it still usefully clarifies polling and failure/cancellation behavior. For a simple one-parameter read-only tool, this is nearly complete, with only minor gaps around rate limits or pagination that may not apply.

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 0% and the only parameter, task_id, is undocumented in both schema and description. The phrase 'owned export task' hints that task_id identifies an export task you own, but it does not explain the UUID format, where to obtain the ID, or what makes a task owned.

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 states a specific verb (poll) and resource (owned export task), and adds that resolved_export and outputs can be inspected even after failure or cancellation. It is clearly distinct from initiating or canceling an export, though it does not explicitly name the sibling tools it differs from.

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?

It implies this tool is for polling an existing export task and checking results after failure/cancellation, but it never explicitly states when to use it versus export_animation, quote_animation_export, or cancel_animation_export. The usage context is inferable but not fully spelled out.

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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that by noting partial outputs, measured media metadata, credit state, and the ownership constraint.

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 a single well-formed sentence with the operation front-loaded and no wasted words. It efficiently packs the scope and key return details.

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 output schema is available, so the description need not fully document return values, and annotations cover the safety profile. It is nearly complete for a simple polling tool, with the main gap being the unexplained task_id parameter.

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 for the single task_id parameter is 0%, so the description should compensate but does not. It refers only to a 'source-video task' and never explains that task_id is the identifier returned by a generation or quote operation.

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 states a specific verb ('Poll') and a specific resource ('owned source-video task'), making the core action clear. It distinguishes itself reasonably from generation/cancellation siblings, though it does not explicitly name an alternative such as preview_video or generate_video.

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?

Usage is implicitly clear: this is a polling tool for an owned source-video task. However, it does not explicitly state when to use it instead of alternatives like preview_video, nor does it mention that the task_id typically comes from generate_video.

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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns enabled models and their supported parameters/capabilities, which is useful but does not go beyond what annotations already imply. Since the description does not contradict annotations, a 3 is appropriate as it adds minimal extra behavioral context.

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 a single concise sentence that is front-loaded with the action and resource. It efficiently covers the key aspects (enabled models, parameters, capabilities) without any fluff, making it easy for an agent to parse quickly. No unnecessary words.

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's simplicity (no parameters, read-only, idempotent) and the existence of an output schema, the description is complete enough. It clearly states what the tool lists and the content categories. It might benefit from noting that it returns a list, but that is implicit in 'List'. Overall, it covers what an agent needs to know.

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, so the description doesn't need to explain any. The baseline is 4 for no parameters, and the description appropriately focuses on what the tool returns, which is helpful for understanding the tool's purpose. No parameter semantics are needed.

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 lists enabled animation models with their supported parameters and capabilities. It uses a specific verb ('List') and resource ('animation models'), and the scope ('enabled') distinguishes it from potentially listing all models, though siblings don't include a similar list tool, making differentiation straightforward.

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 for discovering available models and their capabilities, which is clear from the context. However, it does not explicitly state when not to use it or mention alternatives, but given the sibling tools are for actions like generating or canceling animations, the distinction is implied. No explicit exclusions are provided.

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?

Adds context beyond annotations: the upload is 'short-lived', the PUT must be exactly byte_size bytes, and a follow-up call is required. Annotations cover open-world and non-idempotent behavior, so the description supplements without contradiction.

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, front-loaded sentence that states the purpose and the required subsequent actions with zero waste. Every clause 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?

The output schema handles return values, and the description covers the complete workflow (prepare, PUT, complete). No essential information for calling this tool correctly is missing, including the requirement to use the returned URL and headers.

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 each parameter already described. The description reinforces the 'exactly byte_size' requirement, which is also in the schema, but adds little new semantic information beyond the existing parameter 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?

States a specific verb ('Create'), a resource ('short-lived direct upload'), and the exact follow-up actions (PUT bytes, then call complete_image_upload). This clearly distinguishes it from sibling tools like complete_image_upload and generate_animation.

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 usage sequence: prepare, PUT exactly byte_size bytes, then complete. It does not list alternatives or exclusions, but the two-step flow is unambiguous for the direct-upload use case.

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 idempotentHint=true and destructiveHint=false, but the description adds significant behavioral details: it mentions cost implications ('subject to storage quota and media budgets'), explains the output format ('Returns a signed image URL, not inline image bytes; fetch it without credentials'), and clarifies a limitation ('Does not preview final alpha quality'). These details go beyond what annotations provide and help the agent understand side effects and usage constraints. No contradictions with annotations are present.

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 and well-structured: three sentences that front-load the core purpose, then cover cost/limitations and output format. Each sentence adds essential information without redundancy. It is neither overly verbose nor under-specified, and the most critical detail (what it does) appears first.

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 that an output schema exists (signal: has output schema: true) and the input schema is detailed, the description covers all necessary context for a preview tool: it states the output type (signed URL), cost/budget implications, and the limitation regarding alpha quality. It does not need to explain return values since the output schema presumably does. The description is sufficient for an agent to decide whether to use this tool and what to expect.

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 description does not elaborate on the parameters, and schema description coverage is 0% (the tool description itself mentions no parameters). However, the input schema provides thorough descriptions for both parameters (max_frame_size and timestamps_seconds), including constraints and defaults. The description does reinforce the 12-timestamp limit ('at up to 12 timestamps'), but it adds no new semantic value beyond what the schema already explains. Thus, a baseline score of 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 the tool's function: 'Get a labeled contact sheet at up to 12 timestamps, with actual source times.' It specifies the resource (video), the action (preview), and key constraints. It also distinguishes itself from siblings by noting it 'Uses no AI or credits,' setting it apart from generation tools like generate_video. This makes the purpose unambiguous and easily differentiated.

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 useful context for when to use this tool: it emphasizes that it uses no AI or credits and is subject to storage quota and media budgets, implying it's a lightweight preview option. It also warns that it 'Does not preview final alpha quality,' suggesting it's not for final output assessment. However, it does not explicitly name alternatives like generate_video or state conditions for choosing this over them, leaving some inference to the agent.

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=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the quote_id is short-lived and no credits are spent, which tells the agent this is a cheap preflight call. It omits how long the quote stays valid, which matters because annotations mark it non-idempotent (repeat calls may reprice).

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?

Two tight sentences with no waste; the core action and the key non-effect are both front-loaded. Nothing redundant with the title.

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 explained, and the description covers the pricing purpose and the no-spend guarantee. For a quoting endpoint whose value hinges on the quote's lifetime and its handoff to generate_animation, the vague 'short-lived' is the only meaningful gap.

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?

Only one parameter, and schema description coverage is 100%, so the schema carries the burden of documenting the full AnimationCreateRequest tree. The description adds only the framing that the request must be the 'complete intended animation request', which is marginal beyond what the schema already says.

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 two-part action (calculate credit price, issue a short-lived quote_id) on the animation resource, which is clear and concrete. It differentiates itself from generate_animation by explicitly denying generation, but it never distinguishes itself from the closely named siblings quote_animation_export and quote_video_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 negative framing ('does not start generation or spend credits') implies this is the pricing step to call before generating, but usage is left to inference. No explicit when-to-use statement, no prerequisites, and no routing to quote_animation_export or quote_video_generation for other artifact types.

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 a safe read-only, non-destructive operation, so the description is not required to carry the safety profile. It still adds real behavioral value by disclosing that FPS exports return a resolved sampling summary and that no video is regenerated, which tells the agent this is a cheap preflight that reuses an existing video rather than triggering work.

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?

Two tightly packed sentences with the primary purpose front-loaded and no filler. The second sentence is dense but slightly opaque ('resolved sampling summary') without prior context on what a quote returns.

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-value details are covered, and the quoted-versus-executed distinction is at least hinted at. Still missing for a nested-options tool: where it sits in the quote → export → poll lifecycle, whether the quote is free/consumes credits, and why idempotentHint is false for a read-only operation.

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 reported top-level coverage is 0% (a single `request` wrapper with no description), and the prose says nothing about parameters at all. In practice the nested $defs are richly documented (mode, fps vs frame_count exclusivity, output_formats defaults), so the schema carries the semantics, but the description adds nothing and never even signals that export settings are nested under `request`.

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: quoting an export from an owned source video, which is distinguishable from the sibling export_animation (executing) and get_animation_export (retrieving). However, it never names those siblings, so the quote-vs-execute distinction must be inferred from the tool name rather than the prose.

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 statement of when to call this versus export_animation, get_animation_export, or quote_animation, and no explicit prerequisite such as 'call this before export_animation.' The phrase 'owned source video' hints at an ownership requirement but gives no actionable context or exclusion.

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=true and destructiveHint=false, which the description aligns with by stating it only quotes and does not start production. The description adds minimal context beyond that, such as clarifying it does not handle export or production, but does not disclose what happens after quoting (e.g., whether the quote is persisted or requires authentication). Given the annotations cover the read-only nature, this is acceptable but not rich.

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 a single, concise sentence with no redundant wording. It is front-loaded with the core purpose and exclusions. However, its brevity sacrifices necessary detail, making it more under-specified than efficiently concise.

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 complexity of the request object (with many optional fields like model, ratio, transparency, etc.) and the existence of an output schema, the description is severely incomplete. It does not explain what a quote entails, what the response contains, or how this tool relates to generate_video (e.g., that a quote must precede generation). The description leaves the agent without enough context to use the tool correctly, despite the rich schema and annotations.

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 description provides no information about the 'request' parameter or its nested structure. Schema description coverage is 0%, meaning the description does not mention any parameter details. While the schema itself has field descriptions, the tool description fails to guide the agent on how to construct a valid request, such as ensuring options match the later create call. This is a significant gap for a complex object parameter.

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 action (quote) and resource (source-video generation), and explicitly excludes export and production, distinguishing it from related tools like generate_video and export_animation. However, it does not specify what a 'quote' returns (e.g., cost estimate or feasibility), leaving some ambiguity about the tool's output.

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 it is only for quoting video generation and explicitly states it does not start export or production, which hints at when not to use it. However, it does not name alternative tools (e.g., generate_video for actual generation, quote_animation for animation) or provide explicit conditions for choosing this over siblings.

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