AnimGen

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

The description goes beyond annotations by disclosing that cancellation is best-effort, that in-production work may not stop, and that credits are non-refundable. These are critical behavioral caveats that add significant context beyond the destructiveHint and idempotentHint 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 sentences, front-loaded with the purpose and followed by essential caveats. Every sentence earns its place; no filler or redundancy.

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 simple cancellation tool with one parameter, the description covers the essential behavioral aspects (best-effort, non-refundable) and there is an output schema available. Nothing an agent needs to correctly invoke the tool 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 description coverage is 100% and the schema already explains the animation_id parameter as 'Owned task the user has asked to cancel.' The tool description adds no additional parameter semantics, 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?

The description states a specific verb ('cancel') and resource ('an owned animation'), and the qualifier 'owned' clarifies scope, distinguishing it from cancel_animation_export and cancel_video_generation. It clearly defines 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?

It provides clear context (cancels an animation) but does not explicitly mention when not to use it or point to alternatives like cancel_animation_export. The sibling names imply differentiation, but the description itself lacks explicit 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?

Annotations already declare destructiveness and idempotency. The description adds behavioral context by specifying that only the export is cancelled and the source video is retained, and instructs to continue polling until a terminal state. This goes beyond the annotations by clarifying the scope of destruction and post-call 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?

Two concise sentences, front-loaded with the action, and no fluff. The polling instruction is an essential behavior. Highly efficient and well-structured.

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 simple single-parameter tool with an output schema, the description covers the essential behavior (cancel, retain source, poll). It could explicitly mention the task_id parameter meaning, but the output schema and annotations cover other aspects. It is fairly complete, though a small gap remains.

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 schema has 0% description coverage for the only parameter (task_id), and the description does not explain that task_id is the identifier of the export to cancel. It mentions 'owned export' but does not connect it to the parameter. With low schema coverage, the description should compensate, but it omits any parameter guidance.

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 action ('cancel'), the resource ('owned export'), and a key constraint ('retain the source video for another export'), distinguishing it from other cancellation tools in the sibling list like cancel_animation. It is unambiguous about 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 gives clear contextual guidance: it is for cancelling an owned export and explicitly retains the source video, implying it is the right choice when you want to keep the source for another export. However, it does not explicitly compare to alternatives (e.g., cancel_animation) or state when not to use it, leaving some inference.

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 (destructive, not read-only, idempotent), the description discloses that cancellation is best-effort, requires continued polling, and may not guarantee a refund. This adds meaningful behavioral context that the structured annotations alone do not convey.

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 concise sentences front-load the action and scope, then add crucial behavioral guidance. Every clause earns its place with no redundant restatement of the tool name or 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?

For a single-parameter cancellation tool with a rich output schema and annotations covering mutability and destructiveness, the description provides the essential behavioral expectations: best-effort cancellation, continued polling, and refund caveat. Nothing critical is missing for correct invocation.

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 schema has 0% description coverage, so the description must compensate. It does so by clarifying that task_id refers to an 'owned source-video task,' adding ownership and domain context. For a single obvious UUID parameter, this is sufficient semantic grounding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('cancel') and clearly identifies the resource ('owned source-video task'), distinguishing it from sibling tools like cancel_animation and cancel_animation_export. The phrase 'source-video task' maps directly to the video-generation domain of generate_video/get_video_generation, so an agent can disambiguate it 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 description gives practical context—'Continue polling' and 'cancellation does not guarantee a refund'—but does not explicitly state when to use this tool versus alternatives such as cancel_animation or get_video_generation. Usage is implied rather than named, so it falls short of a clear routing guideline.

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?

Adds real context beyond annotations: the operation is paid (credits), changing selection or FPS produces a new export rather than mutating the existing one, and the source motion is never regenerated. This complements destructiveHint=true (credit spend) and idempotentHint=true without contradicting 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?

Two dense sentences with the cost/approval condition front-loaded and the mutation-semantics caveat second. No filler, though the second sentence packs two distinct ideas (new export only, source never regenerated) together.

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 paid mutation tool with annotations, an output schema, and a richly documented schema, the description covers the essential gaps: approval requirement, credit implication, and idempotency-on-change behavior. Only the relationship to the quote/status siblings is left to inference.

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 50%, and the description does clarify the two top-level approval parameters (quote_id / max_credits) and the selection/FPS semantics. However, it adds little on request, source_video_asset_id vs task ID, or the export option groups, so it only partially compensates for the coverage gap.

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+resource ('Start a paid export from an existing video asset') and identifies the two approval paths (quote_id or max_credits). It is clearly distinguishable from the read/quote/cancel siblings, though it never names an alternative explicitly.

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 a precondition for calling it (an approved quote_id or max_credits) and a rule about what happens on re-invocation with changed selection/FPS. It stops short of explicitly routing the agent to quote_animation_export first vs. using get_animation_export for status, so the workflow relationship is only implied by sibling naming.

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, destructiveHint=true, and openWorldHint=true. The description adds genuine context beyond them: the operation is asynchronous, credits are charged once production begins (cost timing), and the idempotency key should be persisted per logical generation and reused after timeouts. It does not touch the destruction/cancellation path, but the cost disclosure is valuable.

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 short sentences, zero waste, and the core constraint (paid async, prerequisite, idempotency) is front-loaded. Every sentence 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 explained, and the description covers cost, preconditions, and retry behavior for a complex generation tool. The only gap is guidance on cancellation/cleanup of an in-flight job, which siblings handle.

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 documents all four parameters, including that quote_id and max_credits are optional-but-required-one-of and that idempotency_key must be ≥8 chars. The description restates the one-of requirement without adding format, range, or interaction detail, so 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+resource ('Start a paid asynchronous animation') and flags the async and paid nature, which separates it from the read/exporter siblings. It does not explicitly name which sibling to consult first (quote_animation) or distinguish itself from quote_animation/export_animation by name, so it stops short of full sibling differentiation.

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 preconditions: a prior quote_id OR an explicit max_credits limit, plus an idempotency key. The mention of 'prior quote_id' implicitly routes the agent through quote_animation, but it never names that tool or states when NOT to use this one, so no explicit alternatives are given.

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 declare destructiveHint=true, which is a strong signal that this operation has side effects (billing, resource creation). The description adds 'paid' and 'retain the video asset ID' but doesn't disclose the destructive nature, cost implications, or that it consumes credits. It also doesn't mention that the task is async and requires polling, which is critical behavioral context. The description doesn't contradict annotations, but it fails to add meaningful behavioral disclosure beyond what annotations already say.

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 sentence that front-loads the key action ('Start a paid video-only task') and then gives a compact workflow. It's efficient with no wasted words. It could be slightly more structured (e.g., separating the workflow steps), but it's appropriately sized for the complexity.

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 essential workflow (start, poll, retain asset ID) and mentions the payment requirement. However, it doesn't mention that the operation is destructive (per annotations), doesn't explain the async nature explicitly, and doesn't clarify the relationship between quote_id and max_credits. Given the output schema exists and the schema is rich, the description is adequate but has clear gaps around cost and side effects.

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 50%, and the description adds context for quote_id/max_credits ('approved', 'paid') and idempotency_key ('Save the task ID'). However, the description doesn't explain the 'request' parameter structure or the relationship between quote_id and max_credits (mutually exclusive? both?). The schema already documents most parameters well, so the description adds marginal value but doesn't fully compensate for the 50% coverage gap.

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 ('Start'), a resource ('paid video-only task'), and the required payment inputs ('approved quote_id or max_credits'). It clearly distinguishes from siblings like get_video_generation and preview_video by focusing on task creation. However, it doesn't explicitly name a sibling alternative, so it loses one point for not differentiating from generate_animation or 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 description gives clear context: use this when you have an approved quote_id or max_credits, and it tells the agent to save the task ID and poll get_video_generation. It implies this is the creation step in a workflow. It doesn't explicitly state when NOT to use it (e.g., for animation use generate_animation), so it's not a 5.

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, so the safety profile is well covered. The description adds useful context about the kind of data returned (credit state, errors, generated assets), which goes beyond the structured 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?

A single, compact sentence that front-loads the verb and resource and lists the key retrieval targets without redundancy. Every part of the sentence 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 simple read-only getter with one well-documented parameter, complete annotations, and an output schema present, the description is sufficient. Nothing essential is missing for an agent to call this tool correctly.

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 only parameter, animation_id, is already described as 'Owned task ID returned by generate_animation.' The tool description itself does not add any additional parameter semantics, 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?

The description uses a specific verb ('Get') and resource ('animation') and enumerates exactly what is returned: status, progress, credit state, errors, and generated assets. This clearly distinguishes the tool from siblings like get_animation_export and cancel_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?

The description gives no explicit guidance on when to use this tool versus alternatives. There is no mention of 'use after generate_animation' or 'for export status, use get_animation_export instead.' Usage is only weakly implied by the name and parameter description.

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 readOnly, idempotent, and non-destructive behavior. The description adds genuine behavioral value by revealing that the result remains inspectable after failure or cancellation and that resolved_export and outputs are accessible, which goes beyond what the annotations alone communicate.

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, tightly structured sentence that front-loads the core purpose ('Poll an owned export task') and then adds the most important behavioral caveat. Every phrase earns its place; there is no filler or repetition of schema/annotation data.

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 one-parameter polling operation with a rich output schema and strong safety annotations, the description is complete. It covers the action, the ownership constraint, and the noteworthy failure/cancellation behavior. The output schema handles return-value details, so nothing critical 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?

The schema only defines task_id as a UUID-string with zero description coverage, so the description must carry weight. It contextualizes the parameter as belonging to an 'owned export task,' which is helpful, but it does not explicitly state that task_id is the export task identifier or explain the ownership requirement in detail.

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 is specific and action-oriented: 'Poll an owned export task' names the verb, the resource, and the ownership constraint. It also differentiates from siblings like export_animation and cancel_animation_export by focusing on polling/inspection, so an agent can select it correctly without opening schemas.

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 phrase 'Poll an owned export task' provides clear context for when to call it: after starting an export and wanting to check status. It also signals a key use case, 'even after failure or cancellation,' but does not explicitly name alternatives or say when not to use it, so it stops short of full exclusion 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral value by disclosing that polling may return partial outputs and includes measured media metadata and credit state, which is information beyond 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?

The description is a single efficient sentence that front-loads the verb and object and includes only substantive details. There is no redundant restatement of the title or schema.

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 one-parameter polling tool with an output schema and safety annotations, the description is largely complete: it states what is polled, what the response includes, and the ownership constraint. Explicitly saying the task_id comes from generate_video would be helpful but is easily inferred from the sibling tool list.

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 schema only provides task_id with a uuid format and no description, so coverage is 0%. The description compensates by clarifying that the task is an owned source-video task, giving the parameter meaningful context and an ownership constraint beyond the bare 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 uses the specific verb 'Poll' and identifies the resource as an 'owned source-video task', with concrete response aspects: partial outputs, measured media metadata, and credit state. This clearly differentiates it from siblings like generate_video, cancel_video_generation, 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 description gives clear context: use this to poll a source-video task the caller owns, which is distinct from creating, canceling, or quoting. It does not explicitly name an alternative, but the ownership and source-video constraints provide clear situational 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 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.