Wandura

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds non-derivable context: shared kinds are identical for all accounts while product/element are account-scoped and 'never show another account's uploads,' plus a 'Free' cost note. It stops short of describing pagination or how the default limit of 30 behaves.

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?

Front-loaded with purpose, then usage, then scoping and cost, in three tight sentences with no filler. The account-isolation sentence overlaps somewhat with the kind parameter description in the schema, a minor redundancy, but every sentence otherwise 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 read-only, closed-world browse tool with no output schema, the description covers what can be listed, when to call it, and account visibility boundaries. It omits the return shape and limit/pagination behavior, which is a modest gap but not blocking 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?

Schema coverage is 67%, with q and kind documented but limit carrying only a default and maximum. The description's kind guidance ('shared' vs 'yours alone') largely duplicates the schema's own kind description, so it adds little beyond the structured field. Baseline 3 is appropriate given 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?

States a specific verb (browse) and resource (the creative library), then enumerates exactly what is browsable: shared creators, hooks, scenes, and the caller's own products and elements. It also differentiates itself from render_video by positioning itself as the lookup step that precedes rendering.

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 an explicit trigger condition: 'Call this before render_video when the user wants a specific presenter or a saved product instead of one the model invents.' The alternative (letting the model invent a presenter/product) is named alongside the condition that selects this tool, leaving little to 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?

Annotations only declare readOnly=false, idempotent=false, destructive=false, openWorld=true — they say nothing about cost, async behavior, or lifecycle. The description adds three things annotations cannot: that credits are spent, that a job id returns immediately rather than blocking, and that the job completes even without polling, which is critical for an agent deciding whether it must poll.

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?

Four short clauses: action, cost warning, return contract, lifecycle guarantee. Front-loaded with the action and the irreversible consequence (credit spend), and nothing is padding.

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 9-parameter, nested-object, credit-spending mutation with no output schema, the description supplies the essential missing context: cost, async return shape, and follow-up tool. It does not restate parameter constraints (already in schema) and has no output schema to explain away, so only minor gaps remain.

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 89%, so the schema already documents workspace key scoping, run_id, overrides fidelity, project media-pool behavior, and intent semantics in more depth than a description could. The description adds no parameter-level information at all, which is acceptable given the coverage but earns only the baseline.

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 ('Clone a template into a real video generation') and implicitly contrasts with the sibling preview_generation by calling out that this produces a 'real' generation. An agent can distinguish this from render_video, preview_generation, and get_template without opening any schema.

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

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

Routes the agent to the follow-up call explicitly ('call get_generation to follow it') and signals the cost gate ('SPENDS CREDITS'), which tells the agent to be deliberate. It stops short of naming when NOT to use it (e.g. preview_generation as the free dry run), so it is strong context rather than complete routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that the return includes both a status and a result URL, which is useful context, but says nothing about status values, polling cadence, or failure states.

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, front-loaded with the returned data. It is efficient, though its brevity comes at the cost of the missing parameter and behavioral 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?

There is no output schema, so the description should explain return values; it partially does (status + result URL) but omits the set of possible status values and how to poll. For a one-parameter status-check tool this is minimally adequate but leaves gaps.

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 full burden for the single jobId parameter, yet it never names or explains it. 'A generation you created' loosely implies jobId identifies the generation, but no format, source, or validation detail is provided.

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 identifies the resource (a generation you created) and what it returns (status and result URL), letting an agent tell it apart from the render_* creation tools and preview_* tools. It lacks an explicit verb, but the intent — retrieve status/result — is unambiguous.

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 'a generation you created' implies the natural workflow (call after a render_* tool), but there is no explicit statement of when to use this versus preview_generation or the render_* siblings, and no mention of prerequisites like polling.

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 covered. The description adds non-obvious behavioral context the annotations cannot convey: the generation prompt is deliberately omitted from the response, which prevents an agent from assuming a missing field is an error.

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

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

Two short sentences, zero filler. The primary action is front-loaded and the caveat about the missing prompt plus the redirect follow immediately.

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 discloses that the generation prompt is absent from the returned template, which is the key expectation-setting detail. It does not describe what fields are returned or how an unknown id behaves, but for a single-parameter read tool this is close to 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?

There is one parameter with 0% schema description coverage, so the description carries the burden. 'By id' merely restates the parameter name and adds no format, source, or lookup guidance for templateId. This is the minimum viable level given 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 and resource (get one template by id), which is clear enough to distinguish from list/search siblings. It does not explicitly contrast with search_templates or browse_library, but it does name clone_template as the alternative path.

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 conditional: if you want the generation prompt, send an intent to clone_template instead. That routes the agent away from this tool for the cloning use case. It stops short of stating when-not to fetch a template at all, but the alternative routing is concrete.

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/non-destructive, and the description adds genuinely new operational facts: it is free, consumes no credits, makes no provider call, and the prompt is baked in server-side. That is exactly the kind of cost/side-effect context an agent needs before invoking.

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 tight sentences, front-loaded with what is returned, then the no-prompt constraint, then cost behavior. Every clause carries information; nothing is 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 and no parameters, the description must explain return contents, which it does (demo clip, poster image, credit price at two durations), and it covers cost and side effects. An agent has everything needed 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 tool takes zero parameters, so the baseline is 4. The description correctly implies no input is required and explains that only a photo and duration matter downstream, adding mild clarifying value.

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 precise verb+resource (list the 20 one-photo video effects) and enumerates the returned fields (demo clip, poster image, credit price for 5s and 10s). It also distinguishes itself from the sibling render_effect by noting there is no prompt to write, only a photo and a duration.

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?

"Call this before render_effect" gives explicit sequencing guidance and the 'no prompt to write' note clarifies the intended workflow. It does not, however, address when not to use it or how it relates to the other browse/list siblings (browse_library, list_models, get_template).

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds useful non-structured context: 'Free', plus the fact that rows carry `prompt` and `requires` flags that must both be checked before rendering. It doesn't discuss pagination or result size, but the call-before-render contract is the behavior that actually matters here.

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?

Four sentences, densely packed and front-loaded: purpose first, then parameter hint, then the usage imperative, then the row-contract warning. Slightly overstuffed with dashes and parentheticals, but every clause adds actionable 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?

With no output schema, the description must carry the return shape, and it does name the key row fields (`prompt`, `requires`) and the capability categories. It stops short of describing the full row structure (model names/ids, exact field names), which an agent would still have to discover empirically.

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

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

Schema coverage is 100% and the single `kind` enum is already documented with its default in the schema. 'Pass kind to switch between video, image and audio' restates the enum rather than adding format or edge-case detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('list the models you can generate with') and immediately enumerates what each row contains: reference image/video/audio counts and allowed resolution/duration/aspect values. An agent can distinguish this discovery tool from the render_* siblings without opening any schema.

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

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

Gives an explicit sequencing rule against the alternatives: 'Call this before any render so you pick settings that exist instead of guessing.' It also names the alternative family (render tools) and the condition (before calling a render tool) that selects 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 readOnlyHint/idempotentHint/destructiveHint=false, but the description adds concrete, decision-relevant context beyond them: 'Costs nothing, spends no credits, calls no provider.' That tells the agent this is a zero-side-effect dry run, which the annotations alone only imply.

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 tight sentences, front-loaded with the core definition, then the cost guarantee, then the usage rule. No filler; every clause carries weight.

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 9-parameter preview tool with no output schema, the description usefully names what comes back (price plus resulting aspect/duration), which is the key return information an agent needs. It does not enumerate the full response shape, but that is minor given the rich schema coverage.

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 89%, so the schema already documents nearly all nine parameters with real guidance (e.g. workspace key scoping, project charging, overrides semantics). The description adds nothing parameter-specific beyond echoing 'aspect/duration', so the baseline 3 applies.

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

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

States a specific verb (price) and resource (a clone) and immediately scopes it as non-creating: 'Price a clone WITHOUT creating it.' This cleanly distinguishes it from clone_template, which is the actual creation sibling.

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?

Explicitly names the alternative and the ordering: 'Use this before clone_template so the user knows the price...' The agent knows both when to call it and which sibling it precedes, with the reason spelled out.

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

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

Annotations already declare readOnlyHint/idempotentHint and destructiveHint=false, so the description's added value is the cost and side-effect profile: 'Costs nothing, spends no credits, calls no provider' — a claim annotations cannot express. It also discloses that prompts are sent VERBATIM and that provider flags (--seed, --cf, --wm) survive, though it says nothing about authentication requirements (left to the schema) or the 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?

The core promise is front-loaded in the first sentence and every subsequent sentence carries distinct, load-bearing information (cost profile, model-class handling, list_models dependency). It is dense and packs three separate topics into one paragraph, which costs a little readability, but there is 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?

For a 12-parameter, 1-required tool with full schema coverage, the description covers the crucial unknowns: it is free, it creates nothing, it must be preceded by list_models, and some models take no prompt. With no output schema, it only implies what comes back ('the user sees the price') rather than describing the quote, which is the one remaining 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?

Schema description coverage is 100%, so the baseline is 3; the description earns above that by adding cross-parameter logic the schema does not — that `prompt` must be omitted entirely for list_models.prompt='none' models, and that the @name renumbering convention is handled server-side. It does not add per-parameter detail beyond that, so it stops short of 5.

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 precise verb+resource ('Price a render WITHOUT creating it') and immediately names the scope across media types (video, image, audio). It distinguishes itself from the render_* siblings by asserting the non-creating nature, so an agent can route between preview_render and render_video without opening either schema.

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

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

Explicit sequencing: 'Use this before any render_* tool so the user sees the price first', plus a prerequisite step ('Call list_models first and read `prompt` and `requires`'). It also gives a concrete exclusion case — prompt:'none' models (upscale, remove-bg, face-swap) must omit `prompt` and take source media instead.

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 only cover safety flags (readOnly=false, destructive=false, idempotent=false, openWorld=true); the description adds the material behavior an agent must know: it SPENDS CREDITS, the prompt reaches the provider VERBATIM, provider flags (--seed, --cf, --wm) survive parsing, and the call returns a job id rather than finished audio.

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?

Front-loaded with purpose, credit cost, and the get_generation follow-up, and nearly every sentence carries operational information. It is dense and somewhat long with heavy capitalization, and the 'upscale, remove-bg, face-swap' examples are visually-oriented transforms that sit oddly in an audio tool, mildly blunting the sentence's value.

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 12-parameter, no-output-schema, credit-spending mutation tool, it covers the essentials: cost, verbatim provider transmission, async job id + follow-up tool, model-driven prompt requirements, and cross-tool reuse of the result. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the prompt/source-media trade-off driven by list_models.prompt, the fact that `model` is required with no default, and the credit-spend implication of the call. It explains how `prompt` must be omitted rather than merely describing its type.

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?

Opens with a specific verb and resource ('Generate audio') and immediately enumerates the output kinds (voice line, sound effect, ambience, music bed). It also differentiates itself from siblings render_video/render_image and from non-generating models (upscale, remove-bg, face-swap), so an agent can place it in the family without opening a 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?

Gives explicit preconditions and follow-up: 'Call list_models first and read `prompt` ... and `requires`', 'omit `prompt` and pass the source media instead' for prompt:'none' models, and 'call get_generation to follow it'. It also names the downstream route ('URL can be passed into render_video as an audio reference on models that accept one').

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 the write/idempotency profile, but the description adds the critical economics: this SPENDS CREDITS, preview is a costed dry run that creates no job, spends no credits and makes no provider call, and the effect prompt cannot be customized. Those are exactly the facts an agent needs before committing a paid mutation.

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 tight sentences, front-loaded with the credit-spend warning in caps, then the constraint on customization, then the preview escape hatch. Nothing is padded and the most important risk is 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?

With no output schema, the description partly covers returns by saying preview yields the credit price, and it covers the cost and customization constraints of a paid mutation well. It stops short of saying what a non-preview call returns (job handle, status URL, etc.), which is the remaining gap for a 7-parameter write 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 100%, so the baseline is 3; however the description adds useful framing that only three of the seven fields (effect, photo, duration) are real choices, implicitly classifying run_id, project and workspace as optional scoping metadata. It adds meaning but no syntax beyond 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?

States a specific verb (render), a specific resource (a one-photo video effect) and names the sibling list_effects as the source of the slug. It is clearly distinguishable from render_video, render_image and render_audio by the 'one-photo effect' 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?

Explains the operating model (the prompt is server-side and fixed; you only pick effect, photo, duration) and tells the agent to set preview:true for a costed dry run, which is a concrete usage rule. It does not, however, route between this tool and the sibling preview_render/preview_generation tools, so the alternative-selection guidance is incomplete.

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 (readOnlyHint=false, openWorldHint=true, destructiveHint=false) only flag it as a non-destructive write; the description adds the high-value facts that it SPENDS CREDITS, is asynchronous (returns a job id), sends the prompt verbatim, and that some models transform rather than generate and take no prompt. These are exactly the traits annotations cannot 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?

Front-loaded with the action and cost warning, and every sentence carries operational weight (cost, async flow, chaining, model variation). It is dense and somewhat run-on, but no sentence is 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 (a job id) and how to resolve it (get_generation), plus cost, model-dependent prompt behavior, and downstream chaining. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful cross-parameter semantics: it ties `prompt`/`requires` to list_models, explains that source media replaces the prompt for transform models, and clarifies the verbatim/flag-parsing behavior of the prompt. It stops short of explaining run_id/project/workspace behavior in the description, leaving those 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?

States a specific verb and resource ('Generate an image') with concrete example outputs (product shot, background, character reference). It also explicitly distinguishes itself from siblings by naming get_generation for follow-up, render_video for chaining, and list_models for capability checks.

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 sequencing: call list_models first and read `prompt`/`requires`; for prompt:'none' models omit `prompt` and pass source media; call get_generation to follow the job. It also names the alternative flow (render_video chaining) and the pre-condition of checking models before spending.

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 only cover safety flags (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false); the description adds the materially useful traits: it SPENDS CREDITS, the prompt is sent verbatim with provider flags surviving, it returns a job id immediately (async, non-idempotent by design), and some models transform rather than generate. This goes well 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?

Front-loaded with purpose, then cost warning, then routing rule, then workflow. Every sentence carries a distinct decision-relevant fact; nothing is padding despite the density.

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 12 parameters, no output schema, and one required param, the description closes the gaps an agent would otherwise hit: cost, async job-id return with get_generation follow-up, prerequisite list_models lookup, and the prompt-less transform-model case. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description still adds actionable meaning: the verbatim-prompt contract, the need to derive aspect/duration/resolution from list_models, and the rule to omit prompt for prompt:'none' models while passing source media. This complements rather than merely repeats 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?

States a specific verb+resource (render a video) and immediately scopes it against siblings: 'exact control rather than a template clone' distinguishes it from clone_template, and the render_image/render_audio/render_effect family is implied by 'video'. An agent can select this without opening another 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?

Explicit when-to-use ('raw prompt with any model... exact control'), a prerequisite workflow ('Call list_models first and read prompt and requires'), the follow-up tool ('call get_generation to follow it'), and a when-not case (prompt:'none' models omit prompt and take source media). Alternatives are named concretely.

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 this as a safe, idempotent, closed-world read, so the description need not re-establish that. It adds some value by disclosing partial return content ('aspect and duration'), but with no output schema the description should carry more of the return-shape burden (IDs, titles, pagination, rank/order) than it does.

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, front-loaded with purpose, then usage, then return shape. Each sentence carries distinct information and there is no filler or restatement of the tool name.

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 must cover return values, and it partially does. However, for a 4-param search tool with no required params and half the schema undescribed, an agent still lacks guidance on query semantics, defaults, and result volume.

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 only 50%, and the description says nothing about any of the four parameters. The bare 'limit' and 'industry' params are documented nowhere, and the description does not compensate by explaining search matching, format filtering, or result count behavior.

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 ('Search the Wandura ad-template catalog'), and clarifies its role relative to clone_template ('Use this first to find a template to clone'). It does not distinguish itself from other lookup siblings such as browse_library or get_template, so an agent must still infer the boundary.

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 clear ordering cue ('use this first') tied to a downstream action (cloning), which is real when-to-use guidance. It stops short of naming alternatives or exclusions, so it never says when to prefer browse_library or get_template instead.

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?

Goes well beyond the annotations (which only mark this as a non-read-only, non-idempotent, non-destructive write) by disclosing the 50 MB size cap, the cost profile (free, no credits), the ephemeral-vs-persistent consequence of `saveAs`, and the shape of the result. These are exactly the traits annotations cannot express.

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?

Every sentence earns its place: capability, mechanics of `path`, the return value's use, the persistence toggle, and two hard limits (size, cost). The core capability is front-loaded and there is 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 still tells the agent the return value (a URL usable in render_video), the size ceiling, and the cost, which is enough to invoke this 5-parameter tool correctly. Nothing call-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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: `path` causes the server to read and upload the file for you, and `saveAs` controls whether the asset is discoverable later. `kind` and `contentType` are left 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?

States a concrete verb and resource — put a local image/video/audio file where a render can reach it — and names the downstream consumer (render_video) and the library concept, which separates it from the render_* siblings and from browse_library. An agent can tell what it does and what it produces (a URL) 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?

Gives explicit conditional guidance for `saveAs` (add it to persist, omit it and the URL still works but nothing lists it later) and ties the output to render calls. It does not explicitly compare `path` vs `contentBase64` in the description, though the schema covers that choice.

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