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?

Annotations already communicate mutation, destructiveness, and idempotency. The description adds valuable beyond-annotation context: the operation is paid, changing selection or FPS creates a new export rather than modifying the old one, and source motion is never regenerated. No contradiction with the annotations found.

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 filler. The most important information—paid export, existing asset, and the critical behavioral warning—is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich self-documenting schema and presence of an output schema, the description covers the essential high-level context: payment authorization and the key behavioral pitfall. It could mention the quote-first workflow, but an agent can still invoke the tool correctly with the information provided.

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 adds useful meaning around quote_id/max_credits ('approved') and the selection/FPS side effects, but the schema already documents most parameters in detail. With 50% schema coverage, the description only partially compensates and leaves idempotency_key and request-structure semantics to the schema.

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

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

The description names a specific action ('Start a paid export'), a specific resource ('existing video asset'), and the required payment precondition ('approved quote_id or max_credits'). This clearly distinguishes it from source-generation tools like generate_animation and from quote/get/cancel export siblings.

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 when the tool is appropriate: only for paid exports from an already-existing video asset. However, it never explicitly points to quote_animation_export for obtaining a quote, nor does it state what to do when no quote or credits are available. It provides context but no explicit alternatives or exclusions.

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 description adds value beyond annotations by disclosing the paid nature, asynchronous execution, and charge timing ('Credits may be charged once production begins'). This aligns with destructiveHint=true and idempotentHint=true and does not contradict any annotation.

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-load the action, then state prerequisites and cost behavior with no filler. 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?

For a paid, asynchronous, idempotent tool, the description correctly covers the critical invocation requirements and financial side effects. With an output schema present, return-value details need not be in prose; a pointer to get_animation for polling would be a minor improvement but isn't necessary to call the 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%, so the schema already documents all parameter semantics thoroughly. The description restates the quote_id-or-max_credits requirement and idempotency key but adds no parameter-level detail beyond that.

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

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

The description opens with a specific verb and resource — 'Start a paid asynchronous animation' — making the action and object clear. It doesn't explicitly distinguish itself from sibling tools like generate_video, but the payment and animation wording sharpen the identity enough to avoid real confusion.

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 concrete entry conditions: it requires a prior quote_id or an explicit max_credits limit, plus an idempotency key. This tells an agent when the tool is appropriate and what must exist before calling, though it doesn't name exclusions or explicitly route to quote_animation.

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 mark it readOnlyHint=true, and the description adds that it issues a short-lived quote_id and does not spend credits. This goes beyond the annotation by clarifying the side-effect-free nature and the temporary validity of the quote. No contradiction with 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 concise sentences with no fluff. The primary action and the critical non-effect are stated upfront, making the description easily scannable and informative.

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 tool has an output schema, so return values are covered elsewhere. The description adequately covers the purpose and the key behavioral constraint (no generation/spend). The only minor gap is not explaining how the quote_id is used later, but that is likely in the output schema or sibling tool descriptions.

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 parameter 'request' is fully documented in the schema with rich nested descriptions. The tool description itself adds no parameter-specific guidance, but schema coverage is 100%, so the baseline of 3 is appropriate. The description's lack of additional parameter insight is acceptable given the schema's thoroughness.

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 ('Calculate') and a clear resource ('current credit price') and result ('short-lived quote_id'). It explicitly states it does not start generation or spend credits, which distinguishes it from generation tools. The name and context reinforce the animation generation quoting purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage before generation ('does not start generation') but does not explicitly name alternatives like quote_animation_export or state when to prefer this tool. The 'short-lived quote_id' hints at a pre-generation step, but the agent is left to infer the exact selection criteria against sibling 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 readOnlyHint=true and destructiveHint=false, but the description adds key behavioral details: 'FPS exports return a resolved sampling summary and never regenerate the video.' This goes beyond annotations by describing side-effect-free behavior and the promise of returning a summary. However, it doesn't detail the consequences of quoting, such as whether it reserves resources or incurs costs. The description doesn't contradict annotations, so no contradiction flag.

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 two sentences long, front-loads the main purpose, and conveys the most important behavioral caveat (never regenerates the video) in the second sentence. It's concise and well-structured, avoiding verbosity.

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 tool has a rich output schema (though not provided in the context, but it's stated to have one), and the schema details every parameter. The description covers the most critical behavioral aspect (FPS exports return a summary and don't regenerate). However, it doesn't mention the required source_video_asset_id ownership or the distinction from export_animation. Given the tool's complexity, the description could add a note about when to quote versus directly export, but the combination of schema and annotation provides enough context for an agent to call it correctly in most cases.

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 doesn't directly explain parameters, but it hints at the FPS behavior ('FPS exports return a resolved sampling summary'), which relates to the fps parameter. The schema is extremely detailed, with descriptions for every parameter, so the description's contribution is minimal. However, since the schema coverage is 0% (meaning no description text), the description carries a small burden. The description's mention of FPS exports and the requirement for spritesheet and spritesheet_json (mentioned in the schema) is echoed but not expanded. Overall, the description adds a little value by hinting at the FPS-specific behavior, but the schema does most of the work.

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

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

The description clearly states the operation: 'Quote an export from an owned source video.' It specifies the resource (owned source video) and the action (quote an export). However, it doesn't distinguish it from the sibling tool 'export_animation', which likely performs the actual export. The description does hint at a distinction by mentioning 'FPS exports return a resolved sampling summary and never regenerate the video,' but this is more behavioral than clarifying the tool's purpose relative to its siblings.

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 some guidance on when to use this tool (for quoting an export) but doesn't explicitly state when not to use it or how it differs from 'export_animation' or 'get_animation_export'. There's no mention of prerequisites, such as needing to own the source video or having a generation already done. The sibling list includes 'export_animation' but the description doesn't reference it, leaving the agent to infer the distinction. The description does mention that it 'never regenerates the video,' which is a hint for when to use it, but it's not sufficient for clear 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=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.