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

Annotations already mark readOnlyHint=true and openWorldHint=true. The description adds value by noting credit cost ranges for video, but does not disclose further behavioral traits like latency 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 concise sentences: first states the main purpose, second provides usage context. No wasted words, front-loaded effectively.

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?

Fully adequate for a no-parameter, read-only tool with annotations. The description provides essential usage context and a practical example.

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 (schema coverage 100%), so baseline score is 4. Description does not need to add parameter info.

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 the current AetherWave credit balance for the API key' with a specific verb and resource. It distinguishes from sibling tools that involve generation or 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?

Explicitly advises using the tool before generation to confirm sufficient credits, with cost context for video. This provides clear 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, polling, and return of edited image URLs. Includes cost (6 cr per call), time (~30s), and failure modes (URLs with spaces/parentheses). No contradiction with annotations (readOnlyHint=false, openWorldHint=true).

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 headings and bullet points. Every sentence adds value. Slightly long but justified by complexity. Front-loaded with core action, then detailed model guide.

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, openWorldHint=true, and no output schema, the description is thorough. Explains return behavior, default model, cost, time, and caveats. Covers all needed context for an agent to use 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?

Despite 100% schema coverage, description adds significant value: explains default model, cost, output count, speed, and model trade-offs. For imageUrl, warns about clean URLs. For model, provides detailed usage scenarios 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?

Title and description clearly state it edits an existing image using AI with a text prompt. The verb 'edit image' and resource 'public imageUrl plus prompt' are specific. Distinguishes from siblings like generate_image, remove_background, etc.

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

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

Provides an explicit model selection guide with when to use each model, default behavior, and fallback. Includes a concrete instruction: 'If the user simply says "edit this image" with no other signal, default to grok-imagine-i2i.'

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?

Describes the job submission and polling process, credit costs, and the importance of aspectRatio. Annotations add minimal behavior info (readOnlyHint false, destructiveHint false), so the description carries the burden. It does not explicitly mention timeout behavior or error handling upon failure, which is a minor gap.

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 a main paragraph followed by a bullet-point model selection guide. It is lengthy but appropriate given the tool's complexity (8 parameters, multiple models). Could be slightly more concise, but the organization makes it easy to scan.

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 usage, model selection, parameter details, and when to ask the user. No output schema exists, so the description should explain the return format, which it does succinctly ('returns the final image URLs'). Missing details on error handling or pagination, but sufficient for the tool's 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 coverage is 100% (all 8 parameters documented). The description adds substantial value beyond the schema: detailed model selection guide, referenceImages usage, aspectRatio criticality, and numImages constraints. For example, the model parameter schema only says 'Defaults to...', while the description provides a comprehensive decision tree.

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 images from text or text+reference images, specifies the default model and ability to get multiple outputs, and distinguishes from sibling tools like aetherwave_edit_image for I2I modifications. The verb 'Generates' is specific and the resource 'image' is clearly defined.

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

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

Provides an extensive model selection guide with explicit when-to-use recommendations based on user intent (e.g., single high-quality output, photoreal, NSFW, cheapest). Also advises when to use aetherwave_edit_image for I2I changes and when to ask the user (contradictory prompts, expensive generations). Covers exclusion criteria and alternatives thoroughly.

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 polling behavior, error handling (transient GENERATE_AUDIO_FAILED errors, retry advice), and title advisory for instrumentals. Adds value beyond annotations which only show basic read/destructive 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?

Four sentences covering key points with no fluff. Front-loaded with primary action and important details.

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?

Handles all critical aspects: generation action, return count, timing, error handling, parameter nuances. No output schema exists, but description sufficiently sets expectations.

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?

Enhances schema descriptions by noting default model V5.5, instrumental suppresses vocals, and title behavior for instrumentals. Schema coverage is 100%, so description provides additional 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?

Description clearly states it generates AI music via Suno, returns two tracks, and defaults to V5.5. Differentiates from sibling tools like generate_image and generate_video by specifying 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 context for instrumental output, model selection, and timing (30-90s with a 6-minute budget). While it doesn't explicitly name alternatives, the sibling tool list makes it clear when to use this tool versus others.

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 are minimal (readOnlyHint false, etc.), but the description adds critical behavioral context: polling with 8-minute timeout, default model fallback, cost per second, audio inclusion, cost impact of resolution/duration. 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 but well-structured with clear sections (model selection guide, audio, cost framing). Every sentence adds value; however, length could be slightly trimmed without losing clarity. Front-loaded with core behavior.

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

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

Given the complexity (8 parameters, many models, no output schema), the description is remarkably complete. It covers model selection, cost, audio, I2V requirements, and polling behavior, leaving no major gaps for 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?

Schema coverage is 100%, but the description adds significant meaning beyond the schema itself. It explains default model, duration ranges per model, resolution default, requirement of imageUrl for I2V, mode only for Grok Imagine, and maps model selection to 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 generates a short-form video from text or text+image. It distinguishes itself from sibling tools like generate_image and reframe_video by specifying T2V and I2V modes and providing a detailed model selection guide.

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 extensive model selection guide with explicit signals for when to use each model (e.g., 'highest quality' -> veo3.1-quality). It also advises when to ask the user (cost >100 credits, ambiguous 'best'). This is exemplary usage 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 indicate readOnlyHint=true and openWorldHint=true. The description adds rich behavioral context: what the response contains (credit cost, aspect ratio, inputs, options) and how the model key is used as a parameter in generate_image.

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

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

The description is two sentences with no wasted words. The first sentence front-loads the purpose and return contents, the second provides usage guidance. Every sentence is informative.

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

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

Given no parameters and no output schema, the description fully covers what the tool does and how to use its output. It is complete for a list tool with zero parameters.

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 no parameters, so schema coverage is 100% trivially. The description adds value by explaining the return format and usage of the model key, going beyond the schema. Baseline for 0 params is 4.

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 explicitly states the tool returns every image-generation model with details like credit cost, aspect ratio, supported inputs, and options. It clearly distinguishes from sibling tools like aetherwave_list_video_models by 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 says 'Call this before generate_image when you don't know the right model ID,' providing clear when-to-use guidance. It does not explicitly mention when not to use, but the context of sibling tools offers 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?

Annotations declare read-only and open-world hints. The description adds that it returns exactly 12 presets with specific styles and values, complementing the annotations without contradiction.

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

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

Two concise sentences with front-loaded purpose, plus a list of preset styles. Every sentence is informative and there is no fluff.

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 covers all necessary context: what is returned, when to call, and why. No gaps remain for this simple listing 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?

No parameters exist (schema coverage 100%), so no param info needed. The description fully communicates what the tool outputs, which is the only relevant semantic information.

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 all AI mastering presets with specific details (LUFS, tags, descriptions, difficulty). It distinguishes from the sibling tool 'aetherwave_master_audio' by indicating when to call this one first.

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 tells when to use: 'Call this before master_audio when you don't know which preset fits the track.' Also mentions matching distribution target via LUFS values.

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 that it returns the authenticated user's gallery items and lists specific fields, providing useful context without contradicting 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?

Concise, well-structured description with purpose first, then examples, then field listing. No extraneous text.

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 operation with well-documented parameters and no output schema, the description sufficiently explains what is returned (fields) and supports pagination/filtering. Complete enough for agent usage.

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% with clear descriptions for all parameters. The description does not add significant new parameter detail beyond what the schema provides, so 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 'Returns items from the authenticated user's gallery' with specific media types (images, videos, audio tracks) and lists the fields returned. This distinguishes it from sibling tools that generate or edit content.

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 concrete agent workflow examples ('find my last 5 images and reframe them...') and mentions pagination/type filtering. It does not explicitly state when not to use, but the context from siblings 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 already declare readOnlyHint=true and openWorldHint=true. Description adds value by detailing the returned attributes (credits, durations, etc.), which is beyond what annotations provide. 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?

Single sentence, efficiently lists returns and usage instruction. No superfluous text.

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 no parameters, no output schema, and comprehensive annotations, the description fully explains the tool's purpose, output content, and usage context. Complete for a read-only list 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?

Input schema has no parameters, so description need not add parameter info. Baseline 4 for 0 parameters, no additional meaning needed.

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

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

Clear verb 'returns' with specific resource 'every video-generation model AetherWave supports' and explicitly lists the attributes (credit cost, durations, etc.). Distinguishes from sibling tools like list_image_models by focusing on video models and connecting to 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?

States 'Call this before generate_video when you don't know the right model ID,' providing a clear when-to-use instruction. Lacks explicit when-not-to-use but context is implied.

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

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

Discloses synchronous nature with internal polling and expected time (30s-5min), cost (20 credits, free for higher plans), output format (WAV, ~50MB), and lossless quality. Annotations already present; description adds significant 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?

Efficient single paragraph that front-loads key action and time expectation, then provides usage context, cost, output, and preset guidance. 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?

Adequately covers return value (mastered URL), output format, and size. With no output schema, description explains what agent receives. Slightly missing explicit response structure but sufficient for a straightforward 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% with descriptions. Description adds value by explaining preset steers style, recommends calling list_presets for details, and lists examples. TrackTitle context ('used in gallery row label') is extra.

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 a mastered URL. Distinguishes from siblings by noting it's a final polish step after music generation and references aetherwave_list_master_presets. Specific verb and resource.

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 says 'Useful as a final polish step after music generation,' implying when to use. Does not give explicit when-not-to-use but provides context on cost and plans. References sibling tool for preset selection.

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 non-readonly and non-destructive behavior. The description adds valuable transparency: it specifies the outpainting approach, speed tiers with credit costs, and that it returns a 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?

Three sentences, each purposeful: first defines the core action, second lists required parameters, third details optional parameters with costs. No redundant 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?

The description covers inputs, behavior (outpainting), optional parameters, and output (URL). It lacks details on potential limitations (e.g., image size constraints) but is sufficiently complete for typical use given the tool's moderate 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 coverage is 100%, but the description enhances understanding by providing examples for aspectRatio ('16:9', '9:16', etc.) and clarifying the meaning of each speed tier with its credit cost. This goes beyond the schema's basic 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 uses a specific verb ('reframes an image to a new aspect ratio') and resource ('image'), and clearly differentiates from the sibling 'aetherwave_reframe_video' tool. It states the intelligently outpainting behavior, making the purpose unmistakable.

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 how to use the tool (pass imageUrl and aspectRatio) and explains speed tier options with costs. However, it does not explicitly state when to use this tool over alternatives like 'edit_image' or 'upscale_image', leaving room for ambiguity.

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 this is not read-only, destructive, or idempotent. The description adds useful behavioral context: credit cost (17 credits per second) and the output type (R2-hosted URL). 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?

Three front-loaded sentences covering action, parameters, cost, and output. No unnecessary words; every sentence adds 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?

No output schema, but description specifies the return (reframed video URL). All parameters are explained, and the cost is mentioned. 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?

Schema coverage is 100%, but the description adds meaning beyond enum values and types: explains videoUrl as public URL, reframeAspectRatio as target ratio from enum, and provides an example for reframePrompt ('extend the sky with sunset clouds').

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 reframes a video to a new aspect ratio using outpainting/cropping, distinguishing it from the sibling tool aetherwave_reframe_image. The verb 'reframes' and resource 'video' are 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?

The description mentions required parameters (videoUrl, reframeAspectRatio) and optional reframePrompt, but does not provide explicit guidance on when to use this tool vs alternatives like aetherwave_reframe_image. No exclusions or when-not-to-use 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?

Discloses credit cost, auto-fallback between providers, and performance on different input types. Adds significant context beyond annotations, which only set openWorldHint=true and no destructive 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?

Four sentences, front-loaded with main action. No fluff. Each sentence adds 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?

Given single param and no output schema, description fully explains purpose, usage, cost, fallback, and limitations. Agent can correctly decide to use this 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 covers 100% of the single parameter with description. Description adds 'public' qualifier but not much else. 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?

Clearly states it removes background and returns PNG with alpha. Distinct from siblings like remove_background_video. Specific verb+resource.

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 use cases (product shots, etc.) and limitations (transparent PNG). Lacks explicit when-not-to-use compared to alternative tools like edit_image, but covers fallback behavior and credit cost.

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 are minimal, but the description adds critical behavioral details: credit cost per second, processing time estimates, output format (R2-hosted URL), and the frame-by-frame nature. This fully compensates for the lack of detailed 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?

Four well-structured sentences with no waste. First sentence sets the core action, second explains modes, third gives performance/cost, fourth covers best use and output. 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?

Despite no output schema, the description specifies the output is a processed video URL. Input schema is clear. All necessary context is provided: what, how, cost, performance, limitations, and output. 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 already covers parameters with descriptions, but the description adds practical meaning: explains the effect of bgType choices (alpha WebM vs solid color), gives an example hex for customColor, and states the default. Enhances usability 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?

Clearly states the action (strips background) and specific resource (video) using a named service (rembg u2netp). Differentiates from sibling 'aetherwave_remove_background' by specifying video and frame-by-frame processing.

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 guidance on best use cases (clear edges, people, products) and performance expectations (slow, per-frame processing). Could be more explicit about when not to use, but the slowness warning implicitly discourages use for quick results.

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 a mutation (not read-only). The description discloses credit cost behavior and notes that upscaling returns a URL. It adds useful context beyond annotations without contradiction.

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

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

Three concise sentences: purpose, inputs, and result/cost. Information is front-loaded and every sentence adds value with 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?

With 2 parameters and no output schema, the description explains inputs, cost, and return value. It is nearly complete; could optionally mention synchronous behavior but not required.

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. The description adds value by explaining cost implications for upscaleFactor and warning about '8x' usage, providing practical guidance 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 the action (upscales), resource (source image), and tool (Topaz). It distinguishes from sibling tools like aetherwave_upscale_video and other image 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 specifies required inputs (public imageUrl and upscaleFactor) and provides cost guidance based on resolution. It implicitly suggests when to use (upscale an image) but does not explicitly name alternatives or exclusion criteria.

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 etc.), the description adds critical behavioral details: cost per second, Atlas-side limits on duration and source fps, and output format (R2-hosted URL), 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?

Three dense sentences, each earning its place. Front-loaded with primary action, no redundant or vague phrasing.

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, the description covers all needed context: input requirements, constraints, cost model, and output behavior, making it complete for an AI agent to invoke 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?

With 100% schema coverage, the schema defines parameters, but the description adds significant value: cost implications, resolution-specific limits (53s vs 23s), source fps constraint, and return type.

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

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

The description clearly states it upscales a source video to 1080p or 2K using Atlas, specifying inputs and distinguishing it from sibling tools like image upscaling and other video 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?

The description explains the tool's specific use case (upscaling video) and includes constraints, but lacks explicit guidance on when not to use it or alternatives.

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