AetherWave Studio

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not required to cover safety. It adds value by specifying that the balance is tied to the API key and explaining the credit cost range for video, but does not elaborate on other behavioral aspects like rate limits or caching.

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 zero wasted words. The first sentence states the core functionality, and the second provides actionable usage guidance. Information is front-loaded.

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

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

For a simple read-only balance check with no parameters and no output schema, the description is fully complete. It covers what the tool returns, its purpose, and when to use it, integrating cost context for better decision-making.

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 no parameters, and schema description coverage is 100%. Per scoring guidelines, baseline is 3. The description does not add parameter-specific information but provides context on when to use the 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?

Clearly states 'Returns the current AetherWave credit balance for the API key.' This is a specific verb and resource, and it distinguishes from sibling generation tools by implying it is a prerequisite 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 advises to use this tool BEFORE a generation to confirm sufficient credits, especially for video generation which can vary in cost. This provides clear context and when-to-use 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?

Discloses submission and polling behavior, return format (URL(s)), cost (6 cr per call), timing (~30s default), and model-specific behaviors (e.g., slow ~5min for gpt-image-1.5-i2i). Warns about URL pitfalls. No annotation 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?

Well-structured with front-loaded purpose and detailed guide; slightly verbose but every section adds essential context. Model selection table is excellent but could be trimmed.

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 tool with 9 parameters and no output schema, description fully covers return format, polling, edge cases, and model-specific behaviors. No gaps.

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

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

Schema coverage is 100%, but description adds value by explaining default model behavior, prompt examples, and specific parameter contexts like resolution tiers and maxImages for multi-output models.

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?

Description uses specific verb 'edits' and resource 'existing image', with example prompts. Distinguishes from siblings like aetherwave_generate_image by focusing on image-to-image editing.

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?

Contains an explicit model selection guide covering various use cases (single output, NSFW, high quality), default recommendation, and when to use alternatives. Mentions sibling tool list_image_models for full lineup.

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?

Covers process: submits job, polls until terminal, returns final image URLs. Discloses credit costs per model, default model behavior, and model-specific behaviors like multi-output vs single deterministic. Annotations (readOnlyHint=false, destructiveHint=false) are supplemented with full async workflow and mutation 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?

Description is long but well-structured with sections (Model selection guide, I2I guidance, when to ask user). Every sentence adds value, but some redundancy could be trimmed (e.g., repeating default model). Still, clarity justifies length.

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 8 parameters, no output schema, and complex model ecosystem, the description is very complete. It explains process, costs, model selection, parameters, and edge cases. Output is described as final image URLs. No gaps.

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

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

Schema covers 100% of parameters with basic descriptions. The tool description adds significant meaning: explains default model, how to use referenceImages (array or single URL), which models support I2I, negative_prompt, seed, etc. The model selection guide ties parameters to use cases.

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 'Generates one or more images from a text prompt (T2I) or a text prompt + reference image(s) (I2I).' It distinguishes from sibling aetherwave_edit_image for 'change something' intent and mentions list_image_models for model lineup. The verb+resource+scope is very specific.

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 guides when to use this tool vs alternatives: For I2I, prefer aetherwave_edit_image unless specific style transfer, premium, or adult content needed. Provides a comprehensive model selection guide with signals like 'high quality', 'photoreal', 'text inside image', etc. Also advises when to ask 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?

Adds significant behavioral context beyond annotations: returns two tracks, polling mechanism, common transient errors with retry advice, model version behavior. No contradiction with annotations.

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

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

Dense single paragraph with all key information, though could benefit from bullet points for improved scannability. Still efficient and front-loaded.

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

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

Lacks return value details despite no output schema. Mentions 'returns two tracks' but doesn't specify format (URLs, IDs). Polling is described but not how results are delivered. Slight gap in completeness.

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%, but description adds crucial context: instrumental activation, title advisory for instrumentals, lyrics generation fallback, model default, and prompt examples. This meaningfully supplements 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?

Clearly states 'Generates AI music via Suno' with a specific verb and resource. Distinguished from sibling tools like aetherwave_generate_image and aetherwave_generate_video by focusing on music generation.

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

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

Provides detailed guidance on when to use: default model, instrumental option, timing and polling budget, error handling. While no explicit alternatives are named, the context of music generation vs other tools 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?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description details polling behavior with an 8-minute budget, default model fallback (KIE -> fal.ai), cost ranges per model, audio inclusion, and resolution-driven cost differences. 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 long (multiple sections and bullet points) but well-structured and front-loaded with the core purpose. Each sentence serves a purpose given the tool's complexity. Could be slightly shortened, but clarity is not sacrificed.

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 8 parameters, no output schema, and minimally informative annotations, the description is remarkably complete. It covers model selection, cost, duration, audio, resolution, I2V requirements, NSFW handling, and first+last frame interpolation. It leaves almost no ambiguity.

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%, but the description adds substantial value: for 'model' it explains defaults and fallback; for 'duration' it specifies model-specific ranges; for 'resolution' it links to cost; for 'imageUrl' it clarifies I2V requirement; for 'mode' it mentions moderation. It also provides practical constraints (e.g., max 15s for Grok).

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 generates a short-form video from text or text+image, including multiple models. It distinguishes itself from sibling tools like list_video_models by specifying that this tool submits, polls, and returns the final video URL.

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 exhaustive model selection guide with explicit signals (e.g., highest quality, cinematic camera moves, cheapest test). It instructs when to ask the user (e.g., single generation >100 credits) and when not to (e.g., default to grok-imagine-t2v). It also covers cost framing and audio pricing.

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 read-only and open-world; description adds beyond by listing returned fields (credit cost, aspect ratio, etc.) and noting the model key format.

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, every word earns its place. Front-loaded with purpose and immediate usage context.

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 no output schema, description lists all relevant fields and cross-references generate_image, fully equipping the 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?

No parameters exist, so description need not explain them. Baseline 4 for zero-param tools.

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 every image-generation model with details like credit cost, aspect ratio, supported inputs, and options. It is distinct from siblings like aetherwave_list_video_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?

Explicitly advises calling this before generate_image when model ID is unknown, providing clear when-to-use and how-to-follow-up guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating no destructive side effects and no exhaustive list. The description adds value by specifying that all 12 presets are returned with their attributes (e.g., target LUFS for streaming is -14), which goes 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 concise with three sentences: first sentence states purpose and output, second sentence provides usage guidance, third sentence gives concrete details. No wasted words, front-loaded with key information.

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

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

Given 0 parameters, no output schema, and annotations providing safety context, the description is complete. It covers the tool's purpose, when to use it, and what to expect (12 presets with relevant metadata). No obvious gaps.

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

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

There are 0 parameters, and the schema coverage is 100% (empty properties). The description implicitly covers the parameter semantics by indicating no input is needed. According to guidelines, baseline is 4 for 0 params, and the description is adequate.

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 'Returns every AI mastering preset AetherWave supports' with specific attributes (LUFS, tags, etc.). It distinguishes from the sibling tool 'aetherwave_master_audio' by explicitly recommending to call this first when uncertain about the preset.

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 advises: 'Call this before master_audio when you don't know which preset fits the track.' This gives clear context for when to use the tool versus alternatives, and implies that if the preset is known, this tool may be skipped.

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 behavioral details: it lists the exact fields returned (id, type, prompt, model, etc.), mentions pagination and type filtering, and notes type-specific fields. This goes beyond the annotations to inform the agent about the output structure and capabilities.

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 long, front-loaded with the core purpose, followed by usage examples, then a detailed list of returned fields and capabilities. Every sentence adds value without redundancy or filler.

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

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

For a listing tool with 4 optional parameters and no output schema, the description adequately covers purpose, typical workflows, pagination, field details, and type-specific attributes. It provides enough context for an agent to understand what data to expect and how to use the parameters effectively.

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% (all 4 parameters described in schema). The description mentions pagination and type filtering, which aligns with the parameters, but does not add significant semantic depth beyond the schema. The use case examples imply parameter usage but are not explicit about parameter values. Baseline of 3 is appropriate given schema completeness.

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 ('Returns') and resource ('items from the authenticated user's gallery'), clearly distinguishing from sibling tools which are about generation, editing, and other operations. It lists concrete subtypes (images, videos, audio tracks), making the tool's scope 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 provides explicit use cases like 'find my last 5 images and reframe them' and 'list my recent songs and master each one', which illustrate when to use this tool. It mentions support for pagination and type filtering. However, it does not explicitly state when not to use it or direct to alternatives, though the sibling tool names imply the differences.

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. The description adds valuable behavioral context about the returned data (cost, durations, resolutions, I2V flag), enhancing transparency beyond annotations.

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

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

Two sentences, front-loaded with crucial details, no filler. Every sentence earns its place.

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

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

No output schema, but the description enumerates returned fields comprehensively. For a listing tool with no parameters, this covers the context adequately.

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?

No parameters exist, and schema coverage is 100%. The description adds no param info, which is appropriate. Baseline 4 for zero parameters.

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 returns every video-generation model with detailed info, naming specific models and attributes. It distinguishes from sibling tools like list_image_models by focusing on video 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?

Explicitly states 'Call this before generate_video when you don't know the right model ID,' providing clear context for use. Lacks explicit when-not-to-use, but the guidance is sufficient.

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 synchronous polling (30s-5min), cost, free plans, output format (WAV, ~50MB), and preset steering. Adds far beyond 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?

Long but each sentence adds value. First sentence captures core purpose. Could be slightly tighter but not verbose.

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 no output schema, covers timing, cost, plans, output details, and preset metadata. Highly complete for a complex 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%. Description adds preset list reference, audioUrl format, and optional trackTitle purpose. Could include more on trackTitle usage.

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?

Clearly states it submits audio for AI mastering and returns URL. Distinguishes as final polish after music generation, and references sibling tool for preset list.

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

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

Specifies when to use (final polish), cost, and plan details. Does not explicitly state when not to use but provides enough context for decision.

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 significant context beyond annotations: it explains the outpainting approach, speed tiers and their costs, default behavior, and return value. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, etc.).

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

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

Two sentences, front-loaded with purpose, then details. No wasted words. Efficient and easy to parse.

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, it describes the return value (reframed image URL). It covers all key aspects: inputs, behavior, speed options, and output. Complete for the task.

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?

Despite 100% schema description coverage, the description adds substantial value: explains speed tiers with cost, provides examples of aspect ratios, and mentions default speed. It enriches parameter understanding beyond the schema.

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

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

The description clearly states it reframes an image to a new aspect ratio via outpainting. The verb 'Reframes' and the resource 'image' are specific. It distinguishes from siblings like reframe_video, remove_background, and upscale_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?

The description tells when to use (reframing an image to a new aspect ratio) and provides speed tiers with costs, aiding selection. It does not explicitly exclude alternatives or state when not to use, but sibling context helps.

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 non-destructive (destructiveHint=false) and read-write (readOnlyHint=false). The description adds behavioral context: intelligent outpainting/cropping, credit cost, optional prompt to steer content, and return format (R2-hosted URL). 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 three sentences: main action, required params, optional prompt and cost, and return. It is front-loaded with the core purpose, and every sentence adds value 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?

Given the tool's complexity (3 parameters, no output schema), the description covers purpose, inputs, cost, and output. It does not specify processing duration or error handling, but it provides enough for an AI agent to correctly invoke the tool. The openWorldHint suggests possible additional effects not described, but overall completeness is high.

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 descriptions for each parameter. The description adds a usage example for reframePrompt ('extend the sky with sunset clouds'), which enhances meaning. For videoUrl and reframeAspectRatio, it merely restates the schema, adding little beyond the baseline.

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

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

The description clearly states the verb 'Reframes' and the resource 'video', and specifies the method ('intelligently outpainting/cropping'). It highlights the required inputs (videoUrl, reframeAspectRatio) and distinguishes from sibling tools like aetherwave_reframe_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?

The description gives clear context: how to use (pass public videoUrl and target aspect ratio), what to expect (outpainting/cropping), and cost information (17 credits per second). However, it does not explicitly exclude alternative tools or provide when-not scenarios, but the sibling names provide implicit differentiation.

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

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

The description adds value beyond annotations by mentioning credit cost per image, auto-fallback on provider outage, and behavior with transparent inputs. Annotations indicate non-readOnly and non-idempotent, but description does not contradict them and adds useful 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 with two sentences: first covers the core function, second adds key details (use cases, credits, fallback, limitations). No wasted words, front-loaded with essential information.

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

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

Given the tool's simplicity (single required param, no output schema), the description is sufficiently complete. It covers purpose, usage, behavior, and limitations. Could potentially mention accepted image formats, but not a critical gap.

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

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

Schema coverage is 100% with only imageUrl, and the schema already describes it as a URI. The description adds that it must be a public URL, but adds minimal extra meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states it strips background from an image and returns a transparent PNG. It uses specific verbs and resources, and effectively distinguishes from siblings like aetherwave_remove_background_video and 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?

The description provides context for when to use (product shots, character cutouts, etc.) and mentions the fallback behavior and best-use case (photographic subjects). It lacks explicit 'when-not-to-use' guidance but implies limitations with transparent-PNG inputs.

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 key behavioral aspects: frame-by-frame processing, model used (rembg u2netp), output types (alpha WebM or solid color), credit cost, speed estimates, and output format (R2 URL). No annotation 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?

The description is compact, every sentence adds distinct information, and it is front-loaded with the core function. No unnecessary words.

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

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

Given the tool's complexity and lack of output schema, the description sufficiently covers input, behavior, performance, and output format, making it complete for agent use.

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%, but the description adds value by explaining the behavior of bgType options (alpha-channel WebM, solid replacement) and providing an example hex for customColor, which aids understanding beyond parameter names.

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

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

The description clearly states the action ('Strips the background from a video frame-by-frame') and resource, differentiating from siblings like aetherwave_remove_background (likely for images) 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 performance ('Slowest tool', time estimates) and suitability ('Works best on subjects with clear edges'), helping decide when to use. However, it doesn't explicitly mention alternatives or when not to use it.

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

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

Adds value beyond annotations by detailing credit cost dependency and noting that 8x is heavy. No contradictions with annotations; readOnlyHint=false appropriately indicates mutation.

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

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

Three concise sentences: purpose, parameters with cost hint, return value. Front-loaded with key information, no 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?

Complete for a simple upscale tool: covers input, cost behavior, and output. No output schema needed. Context signals confirm low complexity.

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 covers both parameters with descriptions. Description adds important context like cost calculation and caution for 8x factor, enhancing meaning beyond 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 upscales a source image using Topaz's high-fidelity upscaler, distinguishing it from sibling tools like aetherwave_upscale_video and other image operations.

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 parameters (imageUrl, upscaleFactor) and cost guidance based on resolution and factor. Also advises against using 8x on large sources. Could be improved by stating when not to use the tool.

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 fully discloses behavioral traits: it is a mutating operation (cost per second, limits), returns a URL, and has no idempotency guarantees. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description, which adds crucial details like cost and platform limits that annotations do not cover.

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 highly concise: two sentences plus a few additional facts, all essential. It front-loads the main purpose and then packs in constraints, costs, and return value without redundancy. Every sentence earns its place.

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

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

Given the tool's complexity (2 parameters, no output schema), the description is complete: it covers input requirements, target resolution options with costs and limits, and the return format (R2-hosted URL). No gaps for an AI agent to interpret.

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%, but the description adds significant meaning beyond the schema: it explains that targetResolution defaults to '1080p', that '2k' is more expensive and limited to shorter clips, and that videoUrl must be a public MP4 URL. This helps the agent understand parameter choices and trade-offs.

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: to upscale a source video to 1080p or 2K using Atlas. It specifies the action (upscale), resource (video), and target resolutions, distinguishing it from sibling tools like aetherwave_upscale_image (image upscaling) and other video manipulation 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?

The description provides clear usage context: when you need to upscale a video, with constraints on source FPS (≤30fps), clip length (53s at 1080p, 23s at 2K), and public URL requirement. It implicitly guides when not to use (e.g., if source exceeds limits). However, it does not explicitly compare to other upscaling methods within the same family, but the context is sufficient for an AI agent.

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