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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds two things beyond that: the pre-submit timing window and the credit-refund side effect, which is exactly the kind of consequence an agent needs to weigh before calling a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no filler, with the action front-loaded and the two key constraints (timing, refund) trailing in priority order. Nothing could be removed without losing meaning.

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 destructive tool with annotations covering the safety profile and no output schema, the essentials are present: what it does, when it applies, and the refund consequence. What's missing is the failure/edge behavior (e.g., canceling after submit).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema documents nothing about generationId. The description never clarifies the parameter either, though the name is self-explanatory and the tool takes only one required field, which limits the damage. Baseline 3 for a single obvious identifier.

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?

Specific verb+resource ('Cancel a reserved generation') with a scope qualifier ('before provider submit') that makes it unmistakable against generate/list_generations/get_generation. It never names a sibling explicitly, but the action is inherently distinct from every listed neighbor.

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?

'before provider submit' is a real usage condition that tells the agent when this call is valid, which is more than generic context. It stops short of saying what happens if the window has passed or naming where refunds/timing go wrong, and there is no cancel alternative among siblings to redirect to.

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 the safe read-only profile, and the description adds real value on top: the URL is short-lived and signed, and critically it does not stream bytes into the model context. Remaining gaps are the expiry duration and whether permissions are required to fetch the generation.

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 with a parenthetical that earns its place by preempting the wrong mental model (that this streams file contents). No filler.

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

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

With no output schema, the description correctly explains the return value (a URL, not bytes), which is the key thing an agent needs. It stops short of expiration time and failure behavior for incomplete generations, so it is strong but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single generationId parameter, so the description carries the burden. It implies the ID belongs to a completed generation but adds no format, validity, or error semantics beyond that, only partially compensating 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 (return) and resource (a short-lived signed download URL) scoped to a completed generation. This clearly distinguishes it from get_generation (metadata) and upload_input (the inverse direction) without needing to open either schema.

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

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

'for a completed generation' implies the precondition that the generation must already be finished, which hints that wait_generation may be required first. However, no sibling tool is named and there is no explicit when-not-to-use guidance, so usage is only implied.

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

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

Annotations declare readOnlyHint=false (a write) and destructiveHint=false, so the safety profile is covered; the description adds that text-to-image/video jobs queue immediately and that wait polls up to completion. But it introduces an undefined 'reserve' concept with no corresponding sibling tool, which muddies rather than clarifies the lifecycle.

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, no filler, with the core action and modality routing front-loaded. Slightly dense but each sentence carries operational information.

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

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

No output schema exists, yet the description never says what a successful call returns (e.g., a generation/job id needed for get_generation or wait_generation). The prerequisite note for image-to-video covers the main workflow gap, but the return contract is left for the agent to infer.

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 all four parameters are already documented, including wait's 120s poll cap and the aspectRatio default. The description restates wait rather than adding new 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?

States a specific verb+resource ('Start a Studio generation') and immediately qualifies it by modality type (text-to-image, text-to-video, image-to-video). It partly differentiates from siblings by naming upload_input, though it doesn't clearly contrast with wait_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?

Gives explicit conditional guidance: image-to-video requires calling upload_input after reserve, and wait:true is offered as an inline alternative to polling separately. However, it never names the wait_generation sibling as the non-blocking alternative, leaving that routing implicit.

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 usefully adds the scope ('for this API key'), but says nothing about rate limits, freshness of the balance, or error behavior for invalid keys.

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 names the resource and the scope with zero filler. Nothing could be trimmed without losing information.

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

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

There is no output schema, so the description is the only source of return-shape information, and it does not say whether the balance is a number, a formatted string, or an object with units/currency. For a simple tool this is a modest but real 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?

The tool takes zero parameters, so there is no parameter meaning to convey; the baseline for a no-param tool is 4. The description correctly adds that the balance is keyed to the caller's API key rather than a passed identifier.

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 (Return) and resource (current Studio credit balance) scoped to the API key. It is clearly distinct from the generation-oriented siblings (generate, list_generations, etc.), though it does not explicitly name a differentiating alternative because none exists.

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

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

Usage is implied rather than stated: an agent can infer this is a read-only balance check, but there is no explicit when-to-use/when-not-to-use guidance or reference to a related sibling. For a trivial zero-arg read this is borderline adequate.

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

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

Annotations already declare readOnlyHint and destructiveHint=false. The description adds genuinely non-obvious behavior: outputUrl is a short-lived signed download link, which tells the agent the link expires and must be used promptly. That is real value 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?

Two very short sentences with no filler, and the key constraint (short-lived signed link) is placed in the single condition sentence. Slightly under-specified rather than bloated.

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?

There is no output schema, so the description carries some return-value burden. It hints at a status field and an outputUrl but doesn't enumerate status values or explain what to do while still processing, leaving a moderate gap for a polling-style tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One required parameter (generationId) with 0% schema description coverage, and the description says nothing about it — it only references outputUrl, a response field, not the parameter. The parameter is fairly self-explanatory by name, so this is adequate but not compensating 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 ('Fetch status'), and paired with the tool name the agent understands it retrieves the status of a generation. However, it does not differentiate from siblings like wait_generation or list_generations, so it falls short of a 5.

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?

No when-to-use guidance is given. The description never mentions wait_generation (which presumably polls until completion) or any other alternative, leaving the agent to infer when a single status check is the right call.

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 only the 'recent'/'this account' scoping, saying nothing about ordering, pagination, or what 'recent' means, which is a gap for a list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the resource front-loaded and no filler. It is efficient, though brevity comes at the cost of the missing detail noted elsewhere.

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 list tool with one undocumented parameter, no output schema, and no pagination/ordering info, the description is too thin. The annotations cover safety but the agent still lacks enough to call it 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?

The single 'limit' parameter has 0% schema description coverage and no mention in the description; its default, maximum (100), and effect are undocumented in prose. The description does nothing to compensate 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?

The description states a specific verb (List) and resource (generations) with scope qualifiers ('recent', 'this account'), so an agent knows what it returns. However, it does not distinguish this from sibling get_generation or wait_generation, which also operate on generations.

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 guidance on when to use this versus get_generation, wait_generation, or list_models. The word 'recent' implies a browsing use case but no alternatives or exclusions are named.

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 usefully adds that results include credit costs and workflows, which is behavioral context beyond the annotations, but says nothing about ordering, filtering, or response shape.

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 with no filler. Every clause (models, credit costs, workflows) carries information an agent would want.

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

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

With no output schema, the description does the work of telling the agent what comes back (models, their credit costs, and associated workflows), which is enough to decide whether to call it. A brief note on ordering or completeness of the launch-model set would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing to document and schema coverage is moot. Baseline 4 applies; the description correctly does not invent parameter semantics that don't exist.

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

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

States a specific verb ('List') and resource ('OfflineCreator Studio launch models') and adds what the listing contains (credit costs and workflows). It is clearly distinct from siblings like list_generations or get_credits, though it does not explicitly name those alternatives.

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

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

Usage is implied by the verb and resource: call this to discover available models before generating. There is no explicit when/when-not guidance, but no sibling duplicates this listing function, so the risk of misrouting is low.

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 establish it is a non-read-only but non-destructive write. The description adds a meaningful side effect beyond a plain upload ('then start processing') and a constraint on filePath ('must stay inside the upload root'). It does not disclose overwrite behavior on repeat uploads, credit consumption (relevant given the get_credits sibling), or auth requirements, so it is decent but incomplete.

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 zero waste; the action and its follow-on processing are front-loaded, and the path constraint follows directly. Nothing is padded.

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 6-parameter mutation tool with no output schema, the description covers the core action and one constraint, but leaves the 'wait' parameter's effect and the result of processing unexplained. Annotations carry the safety profile, so the remaining gap is modest but real.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% with filePath, imageBase64, and generationId documented in-schema. The description reinforces the filePath path constraint but adds nothing about wait, aspectRatio, or contentType beyond their enum values, matching the baseline for partial schema coverage.

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

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

Specific verb+resource: uploads a source image and starts processing for a reserved image-to-video generation. It clearly situates the tool in the generation workflow, though it does not name a sibling it differs from (e.g., generate) to sharpen 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?

The phrase 'for a reserved image-to-video generation' implies the prerequisite that a generation must first be reserved, which is useful context. However, there is no explicit when-to-use vs alternative guidance and no statement of when not to use it.

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

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

Annotations already declare a safe read-only, non-destructive profile, and the description adds meaningful behavior: it blocks/polls, terminates on completed/failed/timeout, and completed responses carry a signed outputUrl. It does not state polling interval, timeout default, or what happens on timeout.

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 compact sentences with the terminal-state behavior front-loaded and the output detail second; no filler.

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

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

With no output schema, the description usefully notes the signed outputUrl return, but it omits timeout semantics (default/bounds/unit) and generationId expectations, leaving gaps for a two-parameter blocking tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden, yet it only alludes to a timeout without explaining timeoutSeconds units, bounds, or the purpose of generationId. Most parameter meaning remains undocumented in both places.

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 action (poll) and terminal conditions (completed/failed/timeout), which is clearly distinct from siblings like get_generation and list_generations. It never names those siblings, so differentiation is inferable rather than explicit.

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 polling-until-terminal behavior implies usage after a generation is started, but there is no explicit when-to-use-vs-get_generation guidance or any stated exclusions. Usage context is left to inference.

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