AetherWave Studio

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

Annotations already declare readOnlyHint and openWorldHint, so the safe-read nature is covered. The description adds useful context about video generation costs (30-300+ credits) which helps the agent anticipate financial checks. It does not describe return format, but that is less critical given the simple resource.

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 with no redundancy. The main purpose is front-loaded, and the second sentence adds actionable usage guidance. Every word serves a purpose.

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 zero-parameter, read-only balance tool with no output schema, the description fully covers what it does and when to use it. The cost guidance for video fills the only needed contextual gap. No missing behavior is apparent.

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 has zero parameters, so the baseline of 4 applies. The description needs to explain no parameter semantics; it correctly focuses on the return value and usage context.

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 'Returns the current AetherWave credit balance for the API key' with a specific verb and resource. It distinguishes from sibling generation/editing tools by focusing on a read-only balance check.

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 instructs 'Use this BEFORE a generation to confirm sufficient credits', providing a clear when-to-use context. The video cost range (30-300+ credits) further guides priority usage without needing to name alternatives, as no sibling tool offers balance checking.

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 richly discloses behavior beyond annotations: it returns immediately (async), provides timing estimates, explains the 'pages-partial' state, the skip behavior, and the safe re-run property. This aligns with annotations (idempotentHint, non-destructive) and adds critical operational context the annotations don't 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?

The description is slightly verbose but every sentence carries useful information (cost, core action, timing, partial handling, re-run guidance, next step). It is front-loaded with 'Free' and the primary purpose, and maintains a logical flow.

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 tool with two parameters and no output schema, the description is thorough: it covers what happens (state changes), when to use (after drawing, before export), performance expectations, edge cases (undrawn panels), and re-run safety. No missing information that an agent would need to invoke 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?

Schema description coverage is 50% (only allowPartial has a description). The description explains the behavior influenced by allowPartial (default refusal vs. allowing partial assembly) but does not explicitly name the parameter. projectId is self-evident and needs no extra explanation, so the description adds moderate value over 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 clearly states the specific action: laying out pages from drawn panels, lettering balloons/captions, and marking the book complete. It distinguishes itself from sibling tools like aetherwave_comic_draw (drawing) and aetherwave_comic_export (exporting) by naming the next step and emphasizing the assembly state change.

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 explicitly states when to re-run (after redrawing a panel) and points to the next step (export). The default behavior with undrawn panels and the allowPartial override are explained, though it doesn't explicitly name alternative tools as 'instead of X' – but the sibling context makes this clear enough. Slight gap: it doesn't say when not to use it beyond the partial-page refusal.

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 annotations, the description discloses important behaviors: generated images are added rather than replacing existing ones, images persist in AetherWave storage, edits preserve the same person, approve re-describes the character from the image, and timed-out calls still save images retrievable via status. This is rich behavioral disclosure with no contradiction to 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 long but dense and well-organized, front-loaded with the core purpose and then structured by action. Every sentence contributes operational guidance, including edge cases like timeout behavior and URL expiration. No filler or redundancy appears.

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 two-action complexity and no output schema, the description covers invocation, credit cost, parameter relationships, approval timing, storage durability, and failure fallback. It is slightly incomplete because projectId is required but never explained, and the tool's direct return value is not described; however, both are inferable from the workflow context.

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

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

With schema description coverage at 63%, the description adds substantial meaning: count credit costs, baseUrl requiring editPrompt, approve's imageUrl, and characterId/characterName identification. The main gap is projectId, a required parameter with no description in either the schema or the tool description, though its meaning is likely inherited from the surrounding workflow.

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

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

The description states a specific verb and resource: it gives a comic character a reference image, with two explicit actions (generate and approve). It clearly distinguishes this tool from generic image-generation siblings by emphasizing that this reference is what every panel uses to keep the character consistent, and it names related tools for context.

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 for both actions: generate costs credits and adds options; approve is free and must happen before aetherwave_comic_write_script. It also constrains acceptable image URLs. It does not explicitly contrast this with aetherwave_generate_image or aetherwave_edit_image, but the unique character-consistency purpose is clear enough.

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, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds meaningful behavioral context beyond these: it states that the tool is free, that it returns projectId and characterIds, that nothing is generated yet, and that certain parameters (imageModel, aspectRatio, stylePreset) are 'Locked once created.' It also discloses cost/charging behavior for downstream steps. The only minor gap is that it doesn't explicitly describe failure modes or what happens if required fields are invalid, but the description 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?

The description is long but earns its length: it front-loads the core purpose in the first sentence, then provides a numbered pipeline that is directly actionable. The pipeline list is dense but well-structured. It could be slightly tighter (e.g., the cost details for downstream tools are useful but somewhat tangential to this tool's own invocation), but every section serves a purpose for an agent navigating the workflow.

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 complex 16-parameter tool with no output schema, the description is remarkably complete. It explains the return value (projectId, characterIds), the workflow position, the sequencing constraint with character_reference, the meaning of key parameters, and the locked-parameter behavior. An agent has everything it needs to call this tool correctly and to know what happens next. The absence of an output schema is compensated by the explicit statement of what is returned.

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 16 parameters. The description adds value by explaining the semantic role of key parameters: 'Characters: give each a concrete visualDescription (age, hair, face, clothes, one signature item). The script writer and every panel read it.' It also clarifies that 'custom' artStyle means describing the look in toneNotes, and that the cover is drawn around the protagonist. This is meaningful semantic guidance beyond the schema's field descriptions.

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 clear verb and resource: 'Creates a comic book project (the AetherWave Graphic Novel Engine) and returns its projectId and each character's characterId.' It also explicitly states what it does NOT do ('Nothing is generated yet'), which distinguishes it from later pipeline tools like aetherwave_comic_draw and aetherwave_comic_write_script. This is a specific, non-tautological statement that an agent can act on.

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 an explicit numbered pipeline of all sibling tools, stating the order of operations and when to use each one. It also gives a critical usage rule: 'Do this BEFORE the script: approving rewrites the character's description from the picture, and every panel uses the approved image to keep the face consistent.' This is exactly the kind of when-to-use and sequencing guidance an agent needs.

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 indicate idempotentHint=true and readOnly=false, but the description adds rich behavioral detail: asynchronous return, 1.5–6 minute per-panel timing, 9 credits charged only on success, alreadyDrawing behavior, silent run death on server restart with resume, and maxCredits refusal. This goes well beyond the structured annotations and does not contradict 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 dense but every sentence earns its place, covering async behavior, cost, idempotency, failure recovery, and stop semantics. It is front-loaded with the default action and immediate return, making the most important information available 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?

For a complex, long-running, cost-bearing tool with no output schema, the description covers the essential operational details: start/stop behavior, credit charging, idempotent re-invocation, server-restart recovery, and progress monitoring via a sibling tool. An agent has enough context to invoke it correctly and know 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?

Schema description coverage is only 33%, so the description must compensate. It explains the meaning of action='start' and action='stop', and ties maxCredits to refusing expensive runs. projectId is left to inference, but its role as the comic project identifier is reasonably clear from the parameter name and required status.

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 ('draw') and resource ('comic's panels'), and clearly explains both the 'start' and 'stop' actions. It also distinguishes itself from aetherwave_comic_status by directing progress tracking to that sibling tool. The behavior of drawing pending or failed panels one at a time 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 description gives clear context for when to call it: start draws missing panels, stop halts after the current panel, and it is safe to re-call at any time. It also points to aetherwave_comic_status for progress. It does not explicitly contrast with redraw_panel or state when not to use it, so it stops short of 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?

While annotations already mark this as readOnly and openWorld, the description adds valuable behavioral nuance: it is free, it assumes 4 panels per page, it can run high for short books, and character references add 6 credits each. This gives an agent an accurate model of how the estimate behaves beyond the annotation hints.

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 compact and front-loaded, opening with 'Free' and a clear definition before diving into caveats. Every sentence earns its place: the first defines scope, the second explains estimation behavior with a concrete example, and the third directs the agent to the next steps and cost adjustments.

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 small parameter surface, rich schema descriptions, and annotations, the description provides everything an agent needs to call this tool correctly and interpret the estimate's limitations. Even without an output schema, the description makes the returned quote's meaning clear, and it covers supplementary costs like character references.

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 adds meaningful semantic context by explaining the 4-panels-per-page assumption behind the pageCount parameter and clarifying that the estimate includes both script and panel credits. This goes beyond the schema's basic field definitions.

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 with a resource: 'Quotes a comic before anything is made' and breaks down the quote into script and panel credits. It clearly differentiates this estimation tool from related actions like aetherwave_comic_draw and aetherwave_comic_status by positioning it as a pre-production estimate.

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 explicitly states when to use the tool ('before anything is made') and points to alternatives after the script exists: aetherwave_comic_status for the real creditsToFinishDrawing and aetherwave_comic_draw for maxCredits. It also explains the over-estimation caveat for short books, giving an agent concrete guidance on when the quoted number is less reliable.

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 discloses a rich set of behaviors the annotations cannot express: it costs nothing ('Free'), the link expires in ~a day, files are large (130 MB example), builds may complete async requiring a second call with exportId, only one build per account runs at a time, and a busy service returns retryAfterSeconds. All of this is consistent with readOnlyHint=false and idempotentHint=true, with no contradictions.

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 carries a distinct fact — cost, formats, link TTL, file size, async pattern, concurrency, busy behavior, prerequisite — with zero filler. Key decision information (free, formats) is front-loaded in the first two sentences.

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?

Despite having no output schema, the description documents the response branches an agent needs: a download URL, an exportId for retry, alreadyExporting with projectId, and retryAfterSeconds on refusal. Combined with full parameter coverage and the assemble-first prerequisite, there is no critical gap 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?

With 75% schema coverage the baseline is 3, and the description adds real meaning: it explains what each format actually produces ('epub' is fixed-layout Kindle ready, 'cbz' for comic readers, 'bundle' contains all three plus page PNGs) and clarifies the exportId workflow. The only parameter it doesn't deepen is projectId, which is self-evident.

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?

Uses a specific verb ('builds'/'export') with a concrete resource ('the assembled book'), enumerates all output formats with real meaning, and distinguishes itself from the aetherwave_comic_assemble workflow step via the closing 'Assemble first' hint. An agent can tell this produces a downloadable file vs. the sibling creation/assembly tools 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?

Provides clear when-to-call context: 'Assemble first' states the prerequisite, the exportId retry path explains when to re-invoke, and the concurrency note tells the agent it may receive alreadyExporting instead of a new build. It stops short of naming sibling alternatives explicitly (e.g., using aetherwave_comic_status to monitor), so it doesn't quite earn 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 mark this as destructive, non-idempotent, and read-only=false, so the bar for additional value is higher. The description still adds substantial context: 9 credits charged only on success, 1.5–6 minute asynchronous duration with a stillDrawing return path, retention of dialogue/captions, refusal during active runs, and the need to reassemble afterward. This fully enriches the annotation profile without contradicting it.

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 carries actionable information: cost, substitution behavior, retention policy, timing, failure mode, concurrency restriction, and post-condition. The core operation is front-loaded, and there is no redundant restatement of the schema 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?

This is a high-complexity tool with no output schema, yet the description covers the essential behavioral surface: asynchronous completion, credit charging, content-filter handling, concurrency constraints, cross-tool dependency on status, and follow-up assembly. An agent has what it needs to call the tool correctly and interpret the stillDrawing outcome.

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 prompt and panelId already documented, but the description adds meaning beyond the schema: prompt is explicitly tied to replacing the scene description and to the content-filter rewording strategy, and panelId is tied to failedPanels from aetherwave_comic_status. projectId lacks a schema description, but the tool-level context makes its role clear enough.

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: 'Redraws a single panel, replacing its current image.' It clearly distinguishes this from the sibling aetherwave_comic_draw by anchoring on a single panel and contrasting with a 'full drawing run,' so an agent can tell them apart 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?

The description gives concrete when-to-use guidance: use it for single-panel redraws, avoid it while a full drawing run is active, and re-run aetherwave_comic_assemble if the page was already assembled. It also advises rewording the prompt rather than retrying when a content-filter refusal is encountered, which is explicit operational guidance beyond what the schema provides.

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 readOnlyHint and openWorldHint annotations, the description adds significant behavioral details: the meaning of 'stalled', the fact that no run is active in that state, that server restarts or failures can end runs, and the explicit warning never to treat a stopped run as finished. This is critical for an agent to avoid misinterpreting stale status.

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 compact, front-loaded with the core value ('Where a comic is and what to do next'), and every sentence adds necessary information. The enum explanation and the stalled-run caveat are placed efficiently and do not waste space.

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 sufficiently enumerates the returned data: project status, drawing state, failed panels with reasons, assembled page URLs, character reference images, and nextStep. It also handles the optional projectId behavior and the critical stalled-state scenario, making the tool fully usable without further documentation.

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 description does not need to duplicate parameter details. It does reinforce that omitting projectId lists recent projects and references the panels detail option, but most parameter meaning is already well documented in 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 states the tool's specific purpose: check a comic's progress, report status, drawing state, failed panels, URLs, character references, and nextStep. It clearly distinguishes this status-checking tool from the sibling tools like aetherwave_comic_draw and aetherwave_comic_redraw_panel.

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 clearly explains when to use the tool and even provides conditional guidance: if drawing is 'stalled', aetherwave_comic_draw must be called again, and a stopped run must never be treated as finished. It lacks explicit exclusions for sibling tools, but the context makes the intended use clear.

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 goes well beyond the annotations by disclosing asynchronous completion (2-3 minutes), cost-on-finish with a concrete credit example, the prerequisite of approving character references, and the destructive consequence of deleting every existing page/panel including drawn panels. This is rich, specific behavioral disclosure with no 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?

Every sentence adds necessary operational or cautionary information. The description is front-loaded with the primary action and asynchronous behavior, followed by cost, prerequisite, and destructive warning. There is no fluff or repetition.

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 an asynchronous, destructive, paid operation with no output schema, the description covers all critical operational aspects: what starts, when results appear, cost behavior, required preconditions, and the destructive parameter condition. An agent has enough information to invoke it correctly and avoid data loss.

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 only 50%, so the description must compensate. It strongly clarifies replaceExisting semantics by linking it to destructive deletion of existing panels and drawn art. projectId is not described, but its role is self-evident from the tool name and the required-field context, so the gap is minor.

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

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

The description states a specific verb and resource: it 'starts writing the script' and enumerates the content produced (chapters, pages, panels, dialogue, captions). It also distinguishes its asynchronous nature from the status-tracking sibling tool, making its purpose 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?

It gives clear context: returns immediately, results appear via aetherwave_comic_status, character references must be approved first, and rewriting requires replaceExisting: true when panels exist. It does not explicitly name alternatives to exclude, but the guidance is sufficient for correct use.

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 discloses behavioral details beyond annotations: 'Submits, polls, and returns the edited image URL(s)', cost (6 cr per call), number of variations (2), expected latency (~30s), and the upstream URL-spaces/parentheses failure caveat. These are not captured by the annotations, which only state readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description adds substantial transparency.

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 opening paragraph is front-loaded and direct, with useful examples. The model selection guide is lengthy but well-organized and earns its place given the number of model choices; a small redundancy (default model restated) prevents a perfect score.

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 9 parameters, no output schema, and a complex multi-model decision, the description is remarkably complete: it covers return values (edited image URLs), polling behavior, costs, timing, source URL constraints, and model-specific guidance. It is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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 adds extra meaning by explaining model trade-offs (cost, speed, quality), noting that `imageUrl` must be a 'clean URL', and describing default model behavior. It doesn't deeply elaborate every parameter (e.g., `quality`, `renderingSpeed`), but it compensates beyond the schema for the most important ones.

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+resource: 'Edits an existing image guided by a text prompt.' It then gives concrete examples ('add a moon to the sky', 'swap the background for a neon city') and clarifies required inputs (`imageUrl` plus `prompt`), which clearly distinguishes it from siblings like `aetherwave_generate_image` or `aetherwave_remove_background`.

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 an explicit model selection guide with when-to-use rules ('Need a single deterministic output... -> seedream-v4-edit', 'NSFW edits -> wan-2.5-spicy-i2i') and a default fallback ('If the user simply says "edit this image"... default to grok-imagine-i2i'). It also directs users to `list_image_models` for the full lineup, offering clear alternatives.

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 annotations by disclosing job submission/polling, credit costs, output counts, adult-content routing, and provider aspect-ratio requirements. The description is consistent with readOnlyHint=false and destructiveHint=false, so there is no 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?

The description is long but appropriately structured: front-loaded purpose, then model selection guide, I2I alternatives, and user-confirmation conditions. Every section earns its place given the tool's complexity and 8 parameters.

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?

Even without an output schema, the description explains the return value (final image URLs), job lifecycle, credit costs, and when to ask for user input. This is a complete and actionable description for a complex generative media 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 coverage is 100%, so baseline is 3, but the description adds meaningful context: default model behavior, model selection guide, explicit aspectRatio advice, referenceImages single-URL convenience, and numImages usage. It does not add much for seed or negative_prompt, but those are already well-described in 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 clearly states it generates one or more images from text (T2I) or text plus reference image(s) (I2I), and explains the job lifecycle (submit, poll, return URLs). It distinguishes itself from sibling tools like aetherwave_edit_image and other media generation tools by explicitly covering image generation and model selection.

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 explicit when-to-use and when-not-to-use guidance: prefer aetherwave_edit_image for editing, use I2I models only for specific intents, use list_image_models for full lineup, and includes concrete model selection criteria by prompt signals. It also specifies when to ask the user for clarification.

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?

Discloses non-obvious behaviors beyond annotations: two tracks returned, default model, 6-minute polling budget, advisory title for instrumentals, and common transient errors with retry strategy. This is rich 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 concise: four sentences, every one adding operational value. It front-loads the main action and then packs specifics efficiently without 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?

With no output schema, the description mentions two tracks but not the response structure. However, it covers timing, errors, defaults, and key parameter nuances, which is a strong level of context for a complex generation tool. Missing only formal return format details.

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 already describes all parameters with 100% coverage, so baseline is 3. The description adds extra semantics for the instrumental param and notes about title behavior, plus retry guidance, which is additional value over 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 clearly states it generates AI music via Suno, using a specific verb and resource. It distinguishes itself from sibling tools by naming music generation specifically and adds unique details like returning two tracks per submission.

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 clear operational context: instrumental flag, polling duration, retry behavior. However, it does not explicitly compare to alternatives or state when not to use this tool, falling 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?

The description goes well beyond the annotations (readOnlyHint: false, openWorldHint: true, idempotentHint: false, destructiveHint: false). It discloses polling behavior (up to 8-minute budget), the async option with reasoning about client timeouts, the risk of wrong words despite success status, audio surcharge differences across models, and credit cost framing. This is rich behavioral disclosure that an agent needs to handle a long-running, fallible generation tool safely.

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 long but structured with sections and bullet points, and the core purpose is front-loaded. Most sentences add value—credit costs, fallback behavior, audio pricing, and pitfalls are all actionable. However, it includes a fairly extensive model selection guide that could arguably be condensed to shorter hints, and the cost framing examples ('35x more') are illustrative but verbose. It earns a 4 for being well-organized but slightly over-stuffed.

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 has 11 parameters, no output schema, and significant operational complexity, the description covers all needed aspects: return value (final video URL), async flow, polling budget, model selection, audio handling, consistent-character workflow, and dialogue writing guidelines. It also links to sibling tools like aetherwave_get_job and aetherwave_list_characters. Nothing essential for an agent to invoke this 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?

Even though schema description coverage is 100%, the description adds substantial semantic depth for parameters. It explains that imageUrl is required for I2V, endImageUrl for first+last frame, referenceImages is mutually exclusive with imageUrl and drops reference images when imageUrl is supplied, generateAudio should be true for dialogue, and duration is authoritative with pace adjustment. These insights are not present in the schema and directly affect parameter selection and invocation.

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 precise statement: 'Generates a short-form video from a text prompt (T2V) or a text prompt + starting image (I2V). Submits, polls, and returns the final video URL.' This clearly identifies the verb (generate), resource (short-form video), and flow. It distinguishes from sibling tools like aetherwave_generate_image and aetherwave_edit_image by making video the explicit focus, and mentions the default model to disambiguate further.

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 is exemplary on usage guidance. It provides a detailed model selection guide with explicit conditions: 'highest quality' → veo3.1-quality, 'cinematic camera moves' → seedance-pro-t2v, 'NSFW' → wan-22-nsfw-i2v, and so on. It names the alternative tool list_video_models for full lineup, and gives explicit 'ask the user only when' conditions. It also distinguishes when to use I2V vs T2V and when to call aetherwave_list_characters for consistent characters. No ambiguity remains.

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 readOnlyHint=true, but the description adds non-obvious behavioral context: the job continues server-side and is saved to the gallery even if the client lost connection, and a taskId recovers a render already paid for. This goes beyond the structured annotations and gives the agent important persistence/recovery behavior without contradicting 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?

The description is front-loaded with the core return value, then gives polling cadence, then the timeout recovery case. Each sentence contributes; the billing remark ('you already paid for') is marginally persuasive rather than purely informational, but the overall structure is efficient and focused.

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 polling tool with 2 parameters and no output schema, the description covers the return value, state progress, polling frequency, and a critical failure scenario. It doesn't enumerate possible state values, but that is a minor omission given the schema and annotations already provide a solid foundation.

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%: both taskId and kind are already described in the input schema, including the enum for kind. The description's mention that 'a taskId is enough' reinforces the parameter's role but does not add new semantic detail beyond what the schema provides, so the baseline 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 states a specific verb and resource: 'Returns the current state and, once finished, the output URL(s) for a job submitted with async:true.' It clearly differentiates from generation siblings by focusing on the async polling/recovery use case, so an agent understands exactly what this tool does and when it differs from tools like aetherwave_generate_video.

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

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

Explicit usage guidance is given: 'Poll this every 10-20s' and 'Use it whenever a generation call timed out too.' It also explains why (job keeps running server-side) and the recovery condition (taskId is enough), leaving no ambiguity about when to invoke this tool rather than resubmitting a generation.

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 the tool as read-only and open-world, and the description adds useful behavioral context without contradicting them: it warns that referenceImages replaces rather than augments the hero image, and that paraphrasing identityBlock breaks consistency. This gives the agent operational knowledge beyond the structured annotation hints.

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 longer than average, but it is organized with a clear opening directive and bulleted output explanations, and every section provides operational value. The only slight deduction is that several downstream-use instructions could be consolidated, but the structure makes the length acceptable.

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 carries the burden of explaining every meaningful returned field, and it does so thoroughly: identityBlock, referenceImages, heroImageUrl, voiceId/voiceSpec, personality, negativeLock, and hasApprovedPack all receive concrete guidance. It is sufficient for an agent to call the tool and correctly use its result.

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 optional name parameter is fully documented in the schema (case-insensitive substring filter, omit to list all), and the description does not need to add much. It does not repeat or expand the schema, so baseline 3 is appropriate for high 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?

The description opens with a specific verb and resource: returning the caller's saved UGC characters, and immediately names the core purpose: keeping recurring characters consistent across a production. It also distinguishes itself from any sibling lookup by stating there is no other way to discover whether a character exists, so agents can route correctly.

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

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

It gives an explicit trigger: 'CALL THIS FIRST whenever the request names a person the user already has', with concrete example phrases. It also tells the agent how to use the returned fields downstream, including passing referenceImages to aetherwave_generate_video and appending identityBlock/voiceSpec verbatim, leaving no ambiguity about when and how to invoke 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=true, and the description adds behavioral detail about the returned fields (credit cost, aspect ratio, inputs, options) and how the model key is used downstream. It does not mention rate limits or pagination, but the tool is a simple list with zero parameters, so the added context is sufficient.

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 with no redundancy. The first sentence front-loads the main purpose and return fields; the second sentence gives actionable usage guidance. Every word 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?

Given zero parameters and no output schema, the description fully covers what the tool returns, how to use it, and why it matters. It is complete for its purpose and requires no further elaboration.

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 schema coverage is trivially 100%. The description adds value by explaining that the returned model key is what you pass to generate_image, which clarifies the connection to another tool's parameter even though this tool itself has no inputs.

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 that the tool returns every image-generation model AetherWave supports, listing specific fields (credit cost, aspect ratio, input types, options). It distinguishes itself from sibling tools like aetherwave_list_video_models by explicitly focusing on image models.

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 explicitly says 'Call this before generate_image when you don't know the right model ID', giving a clear when-to-use directive and tying it to a sibling tool. It also implies that generate_image is the consumer of the model key, providing practical context.

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 openWorldHint=true. The description adds valuable context about the return contents (12 presets, style coverage, LUFS examples) that goes beyond the annotations. It does not contradict the read-only nature, though it does not discuss potential rate limits or caching, which are minor for a list operation.

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 compact (four sentences) and front-loaded with the primary action. Every sentence earns its place: returns what, when to use, how many and which styles, and LUFS examples. 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?

Despite having no output schema, the description explains the return values (target LUFS, tags, descriptions, difficulty level) and provides concrete examples. It also covers usage context and breadth of presets, making it fully sufficient for an agent to understand and invoke 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?

The tool has zero parameters, so the baseline is 4. The description correctly says nothing about parameters, and the empty schema needs no further explanation. No additional parameter semantics are required.

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: 'Returns every AI mastering preset AetherWave supports' with specific fields (target LUFS, tags, descriptions, difficulty level). It distinguishes this listing tool from the mastering tool (master_audio) and other sibling list tools by focusing on audio mastering presets.

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 guidance is given: 'Call this before master_audio when you don't know which preset fits the track.' This names the alternative tool and specifies the condition for use, which is exactly the level of when-to-use guidance expected.

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 annotations (readOnlyHint=true), the description discloses pagination support, type filtering, and the exact fields returned including type-specific fields. This gives agents a complete picture of the return payload and behavior without an output schema.

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

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

The description is front-loaded with the main purpose and includes useful examples. The field list is somewhat lengthy but serves as a substitute for an output schema, so it 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 list tool with no output schema, the description sufficiently explains the return fields, filtering, and use cases. It is complete enough for an agent to invoke correctly without additional context.

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 property already documented. The description only restates that pagination and type filtering are supported, adding no extra meaning over the schema. 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 clearly states the tool returns gallery items from the authenticated user, listing exact media types (images, videos, audio). It distinguishes itself from sibling generation/edit tools by being the listing tool for user creations.

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 explicit example workflows ('find my last 5 images and reframe them', 'list my recent songs and master each one'), indicating when to use this tool before editing. It lacks an explicit 'when not to use' but there are no sibling listing tools, so context is clear.

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 the description adds valuable behavioral context by listing the exact data fields returned (credit cost, durations, resolutions, aspect ratios, I2V requirement). This goes beyond the safety hint and helps the agent anticipate 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?

Two sentences, no filler. The first sentence packs the output details and examples; the second sentence provides usage context. Every word 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?

With no parameters and no output schema, the description fully compensates by detailing both purpose and return content. It also gives usage context, making the tool self-sufficient for an agent.

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?

Tool has 0 parameters, so baseline is 4. The description doesn't need to explain parameters; it instead focuses on output, which is appropriate for a zero-argument tool.

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: returning every video-generation model with specific attributes. It distinguishes itself from sibling tools like list_image_models by explicitly focusing on video models and mentioning generate_video in usage.

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 explicit usage guidance: 'Call this before generate_video when you don't know the right model ID.' This tells the agent exactly when to use the tool and implies the alternative (skip if model ID is already known).

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 substantial behavioral detail beyond annotations: synchronous polling ('route polls the Python service internally; expect 30s-5min'), cost ('20 credits per track'), free plan tiers, and output specifics ('WAV (~50MB per 3-minute track, lossless for redistribution)'). These are critical operational facts not present in 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 front-loaded with the core purpose and then packs in relevant operational details (timing, cost, output, presets). While it is long, every sentence carries useful information, though it could be tightened slightly without losing 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 tool with no output schema and 3 parameters, the description is remarkably complete: it covers synchronous behavior, latency, cost, free plans, output format and size, lossless quality, and preset guidance with a pointer to a sibling tool for the live list. The agent has enough context to invoke 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that the preset 'steer[s] the mastering style' and that each preset's target LUFS lets you 'match the distribution target,' which goes beyond the schema's mere enumeration. However, much of the parameter detail is redundant with 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 first sentence clearly states the action and resource: 'Submits an audio file for AI mastering and returns the mastered URL synchronously.' It distinguishes the tool from siblings by positioning it as a 'final polish step after music generation' and by referencing aetherwave_list_master_presets for preset selection.

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 clear context by stating it is 'Useful as a final polish step after music generation,' which implies when to use. It also gives practical constraints like audio URL requirements, expected wait time, and cost, but does not explicitly name alternatives or state when not to use.

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 openWorldHint, so safety is covered. The description adds real value beyond that: it flags the call as free, discloses that the id space is the entire Printful catalog (including hats, contradicting the 'curated' framing when an id is given), and enumerates the per-mode payloads (US in-stock sizes, placements in inches, embroidery thread colours).

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 cost signal ('Free.'), then the two modes, then the routing purpose. Every clause adds decision-relevant information; no filler or repeated name/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?

With no output schema, the description must cover returns, and it does so for both modes with concrete fields. It is complete enough to call correctly; only minor gaps remain (no mention of response size or whether the curated list is paginated).

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 baseline is 3. The description earns above baseline by interpreting the parameter's two regimes (absent = curated list, present = any Printful catalog id including hats) and the shape of what each mode yields, which the schema's one-line description does not convey.

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 the resource (print-on-demand garments, colours, print areas) and precisely distinguishes its two operating modes: without garmentId returns the curated list, with garmentId returns colours/sizes/placements. The agent can identify what it returns without opening anything else.

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 routes the agent: 'Use it to pick garmentId, color and placement for aetherwave_merch_mockup.' It names the downstream sibling and the exact function this call serves, so when-to-use versus aetherwave_merch_mockup is unambiguous.

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 openWorld and non-idempotent, but the description adds far more: the 3-credit cost with refund-on-failure, the 90-second timeout with a taskKey fallback, the fact that mockup URLs are temporary Printful links, and a 20-mockups-per-hour rate limit. This is exactly the behavioral context 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-loads the cost, then the action, then the fallback and returns — a sensible ordering with no filler. The trailing promotional link ('Made with AetherWave Studio') is the one sentence that does not earn 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?

With no output schema, the description carries the return-value burden and does so: printfileUrl, mockup image URLs and their temporariness, plus the taskKey polling path. Combined with the rate limit and pricing, an agent has everything needed to call and follow up 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 coverage is 100%, so the schema already documents color, topIn, widthIn, placement, designUrl and garmentId including defaults. The description adds little parameter-level detail beyond noting that a bad garment/colour/placement is not charged; baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Builds the print file at the garment's own print area and resolution, then renders Printful product mockups.' It is clearly differentiated from its siblings (prepare_design, mockup_status, create_product). The title reinforces this without merely restating the name.

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 routes the agent to concrete alternatives: use the returned printfileUrl with aetherwave_printful_create_product, and poll aetherwave_merch_mockup_status when still rendering after 90s. It also implies the designUrl must come from aetherwave_merch_prepare_design. There is no explicit 'do not use this when...' exclusion, so it stops short of 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 and openWorldHint, so safety is covered. The description adds genuinely new behavioral facts: results are retained only 6 hours and are visible only to the paying account. It does not explain failure states or what a missing/expired taskKey yields, keeping it from a 5.

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

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

A single tightly written sentence with the cost signal ('Free.') front-loaded and the scope details parenthesized. No wasted words, though the parenthetical packs two distinct facts together and could be split for scanability.

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 carries the return-value burden and does state that status and mockup URLs are returned. Retention window and per-account visibility are covered. What is missing is only edge-case behavior (expired tasks, still-rendering state).

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 (taskKey) with 0% schema description coverage, so the description must compensate but only partially does: it implies the key comes from a render started by aetherwave_merch_mockup, but never names taskKey or states its format/source explicitly. Better than nothing, below the 4 baseline for undocumented params.

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: retrieving status and mockup URLs for a render. It explicitly ties the artifact to the sibling that created it (aetherwave_merch_mockup), which helps disambiguate among 30 siblings. Slightly terse about what 'status' values mean, so not a full 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?

The phrase 'of a render started by aetherwave_merch_mockup' implies this is a follow-up poll to that tool, which is useful context. However, there is no explicit when-to-use/when-not guidance, no polling cadence, and no comparison to the generic aetherwave_get_job sibling that might also retrieve job status.

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 substantial context beyond the annotations: a 1-credit cost, the exact output transformation (transparent PNG trimmed to artwork), and the nuanced knockout behavior (only edge-connected background is removed so interior white lettering survives). It also states the primary return field, which annotations alone would 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?

Four dense sentences with the cost and core transformation front-loaded, followed by input forms, the knockout nuance, and the downstream handoff. No filler or repetition of schema content.

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

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

For a 3-parameter tool with no output schema, the description covers cost, input sources, transformation semantics, and the key return field for chaining. Minor gaps remain (no mention of other return fields or of tolerance interaction), but nothing an agent needs to call it 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 schema already documents all three parameters (baseline 3). The description still adds value for 'image' by enumerating accepted source types and for 'knockout' by explaining the edge-connectivity rule, though it says nothing about 'tolerance' beyond what the schema provides.

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 and output: 'Turns an image into a print-ready transparent PNG trimmed to the artwork.' The merch-prep framing and the designUrl -> mockup chain make the intent clear. It does not, however, explicitly distinguish itself from the near-neighbor aetherwave_remove_background, which an agent could plausibly pick for the same input.

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 concrete usage context: accepted input forms (AetherWave media URL, data URL, local file path), when to set knockout=true, and the downstream tool (aetherwave_merch_mockup). No explicit when-not guidance or contrast against the background-removal siblings.

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 discloses key behavioral details beyond annotations: it performs outpainting, has three speed tiers with specific credit costs, and returns a new image URL. It does not contradict annotations (readOnlyHint=false, etc.) and adds useful cost/performance trade-off information. Minor gaps remain about side effects or rate limits, but for a creative tool this is solid.

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 concise sentences, front-loaded with the core purpose and then providing the essential parameter and return information. Every sentence earns its place with no fluff or repetition.

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 tool with only 3 parameters and no output schema, the description covers the main functionality, inputs, speed/cost options, and return value. It does not mention limitations like max file size or file format restrictions, but given the openWorldHint and simple nature, the description is nearly 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 schema already covers all three parameters with 100% description coverage, including the enum values and credit costs. The description reinforces the aspect ratio examples and speed tiers but adds no new parameter-specific meaning beyond what the schema provides, 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 clearly states a specific verb ('Reframes') and a specific resource ('image') with a clear goal ('to a new aspect ratio'). It distinguishes itself from siblings like reframe_video and edit_image by focusing on image reframing via outpainting.

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 for when to use the tool (when needing to reframe an image to a new aspect ratio) and explicitly lists the required inputs and speed options. It does not explicitly name alternatives or state when not to use it, but the sibling list and specific language make the usage context obvious.

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 readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral context: cost (17 credits per second), output format (R2-hosted URL), and the outpainting/cropping mechanism. It also clarifies that the source must be a public URL. No contradiction with annotations; this is a solid disclosure of operation 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?

The description is three sentences, front-loaded with the primary action, and every sentence adds meaningful info: operation, required inputs, optional prompt with example, cost, and return format. There is no fluff or redundancy, making it 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?

The tool has no output schema, so the description's mention of 'Returns the reframed video URL (R2-hosted)' fills that gap. It covers purpose, inputs, optional parameter, cost, and output. It could additionally note potential processing time or failure modes, but the provided information is sufficient for an agent to decide to invoke the tool. Sibling tools are similar but not referenced, yet the context is complete for a typical use case.

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 three parameters. The description adds marginal value by giving an example for reframePrompt and emphasizing videoUrl must be public, but this is largely redundant. Baseline 3 applies because the schema does the heavy lifting; the description does not significantly enhance parameter understanding.

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 purpose: 'Reframes a video to a new aspect ratio by intelligently outpainting/cropping the edges.' It uses a specific verb ('reframes') and resource ('video'), and the mention of 'video' distinguishes it from the sibling reframe_image tool. The title also adds model context (Luma Ray 2 Flash), reinforcing the specific operation.

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 clear context for when to use the tool: to change a video's aspect ratio via outpainting/cropping. It specifies required inputs (public videoUrl and reframeAspectRatio) and optional reframePrompt. However, it does not explicitly compare to alternatives or state exclusions (e.g., 'use reframe_image for images'), though sibling tooling implies this. This is a minor gap, so 4 is appropriate.

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 discloses costs (~5 credits per image), provider fallback behavior (Recraft to fal.ai BiRefNet v2), and failure semantics ('single-image calls never silently fail'). It also addresses edge cases like transparent-PNG inputs, all beyond the sparse annotations. No contradictions 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?

The description is compact and front-loaded with the primary action, followed by key context (cost, fallback, limitations). Every sentence provides value without redundancy or verbose explanation.

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?

Despite having no output schema, the description specifies the return format (PNG with transparent alpha). It covers costs, provider fallback, ideal use cases, and a limitation, making it complete for a single-parameter 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?

The schema already fully describes the only parameter with 'Public URL of the source image' and format uri. The description repeats 'Pass a public `imageUrl`' without adding new semantic detail, so it meets the baseline for high schema coverage but does not improve on it.

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 'Strips the background from an image, returning a PNG with transparent alpha,' clearly stating the verb, resource, and outcome. It distinguishes itself from siblings like aetherwave_remove_background_video by explicitly targeting images and noting the fallback to BiRefNet v2.

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 explicit use cases ('product shots, character cutouts, logo isolation...') and a clear when-not-to-use ('transparent-PNG inputs have no foreground to segment'). However, it does not explicitly name an alternative tool for video or editing, relying on sibling names rather than direct comparison.

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 annotations, the description adds cost (2 credits/second), performance expectations (6s clip ~4 min), limitations (clear edges), and return format (R2-hosted URL). This significantly enriches the behavior profile without contradicting 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?

The description is a single, dense paragraph with no filler. It front-loads the purpose and progressively provides options, cost, performance, and output. Each clause adds distinct 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?

Covers the full lifecycle: input requirements, processing method, output format, cost, and performance caveats. Even without an output schema, it tells the agent what to expect (R2 URL). Given the tool's complexity, this is remarkably 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 schema already defines all three parameters with descriptions (100% coverage), but the description adds relational meaning: it explains how bgType and customColor interact (transparent vs color replacement) and specifies the output format (alpha WebM). This goes beyond the schema's individual descriptions.

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 ('Strips') and resource ('the background from a video'), clarifying the frame-by-frame methodology using rembg. This clearly distinguishes it from siblings like aetherwave_remove_background (image-focused) and other video tools.

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 clear context on when to use it ('Works best on subjects with clear edges') and warns about performance ('Slowest tool in the surface') with concrete timing examples. It does not explicitly name alternatives or exclusion scenarios, but the context is strong enough for an agent to decide.

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 useful behavior beyond the annotations: credit cost depends on source resolution × factor, and it returns the upscaled image URL. Annotations already indicate non-readonly, non-idempotent, non-destructive, and open-world, and the description does not contradict them. It could mention side effects or limitations, but the cost model is valuable.

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

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

Three concise, front-loaded sentences: purpose, usage, and cost/return. 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?

With only 2 simple parameters and no output schema, the description fully covers inputs, output, and cost behavior. It is complete for the tool's complexity and provides enough context 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 100%, so the baseline is 3. The description adds extra meaning by explaining that credit cost is a function of resolution and factor, which helps choose parameters. It also reiterates the need for a public URL, aligning with the schema's format.

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 starts with a specific verb 'Upscales' and a clear resource 'source image', also naming the technology 'Topaz's high-fidelity upscaler'. This clearly distinguishes it from sibling tools like aetherwave_upscale_video or aetherwave_edit_image.

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

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

It gives clear instruction to pass a public imageUrl and upscaleFactor, and provides cost guidance based on resolution and factor. It doesn't explicitly mention alternatives or exclusions, but the image-specific language and sibling tool names make the intended use clear.

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 basic annotations, it discloses per-second costs, Atlas-side limits (clip length, frame rate), and that the result is an R2-hosted URL. This adds meaningful behavioral context about what the tool does and its constraints.

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 focused sentences cover function, usage, cost/limits, and return value. No redundancy or irrelevant details. The structure is front-loaded with the primary purpose.

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 input, constraints, cost, and output URL, which is sufficient given no output schema. It could mention failure behavior but that's not essential. The limits and cost give good operational context.

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 covers 100% of parameter descriptions, so the description doesn't need to add much. It restates videoUrl and targetResolution without adding new semantics beyond what the schema already provides. 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 clearly states the tool upscales videos to 1080p or 2K using Atlas, with a specific verb (upscales), resource (video), and target resolutions. It distinguishes itself from sibling tools like aetherwave_upscale_image and aetherwave_generate_video.

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

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

It provides clear context for when to use: upscaling a video with a public URL, with specified resolutions, limits, and costs. It doesn't explicitly name alternatives but the context is sufficient for most AI agents.

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