Server Quality Checklist

Tool Scores

• image_to_imageA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full responsibility. It discloses behavioral traits: uses WaveSpeed AI, requires English prompts, provides safety checker, and explains request_id for tracing. It also describes the return structure. However, it omits potential rate limits, authentication requirements, or error handling details.

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

  Conciseness4/5

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

  The description is front-loaded with a clear one-sentence summary followed by structured Args/Returns/Examples/Note sections. However, it is somewhat verbose with multiple examples and a note that could be shorter. Still, the structure aids readability and comprehension.

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

  Completeness5/5

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

  Given 8 parameters (3 required), no output schema, and no nested objects, the description is complete. It explains the return structure (status, urls, base64, local_files, error, processing_time) and provides examples showing different usage patterns. No additional context seems necessary for correct tool invocation.

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

  Parameters5/5

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

  Schema description coverage is 0%, meaning the input schema only provides names and types. The description adds substantial meaning: explains that 'image' and 'images' accept URL, base64, or local paths; describes prompt language requirement; specifies range and default for guidance_scale; explains safety checker, output directory, and request_id purpose. This is far beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool generates an image from an existing image using WaveSpeed AI. It effectively distinguishes from sibling tools: generate_video (video output) and text_to_image (no input image). The verb 'generate' and resource 'image from an existing image' are specific.

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

  Usage Guidelines3/5

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

  The description provides examples and notes about English prompts, but lacks explicit guidance on when to use this tool versus alternatives like text_to_image or generate_video. The usage context is implied through examples but no exclusions or when-not scenarios are mentioned.

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

• text_to_imageA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it generates images, includes a safety checker, specifies default values for steps and size, and outlines the return object (status, URLs, base64, local files, processing time). No contradictions or hidden behaviors.

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

  Conciseness4/5

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

  The description is well-structured with Args, Returns, Examples, and Note sections. It is front-loaded with the purpose. Some detail is lengthy but necessary given the 0% schema coverage. Minor redundancy exists (e.g., English requirement repeated), but overall it earns its space.

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

  Completeness5/5

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

  Despite no output schema, the description fully specifies the return structure and includes examples. It covers all 11 parameters with defaults and constraints. The tool's complexity is high, but the description is complete and self-contained.

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

  Parameters5/5

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

  The schema coverage is 0%, so the description must explain each parameter. It does so thoroughly: prompt is required and must be English, loras has a specific format, size is 'width*height', num_inference_steps affects quality/time, guidance_scale controls text adherence, etc. This adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description opens with a clear verb-resource pair: 'Generate an image from text prompt using WaveSpeed AI.' It explicitly states the action and resource, and the resource type (text-to-image) distinguishes it from sibling tools like generate_video and image_to_image.

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

  Usage Guidelines4/5

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

  The description provides clear usage guidelines, such as requiring prompts in English and noting that non-English prompts will be rejected or produce poor quality. It also includes default values and parameter descriptions. However, it does not explicitly state when to use this tool over siblings, though the purpose implies it.

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

• generate_videoA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: it describes the generation process, parameter effects (e.g., guidance_scale controls text adherence, num_inference_steps affects quality/time), return values (status, urls, base64, local_files, error, processing_time), and even notes on language handling. 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.

  Conciseness5/5

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

  The description is appropriately structured with sections for Args, Returns, Examples, and Notes. Every sentence is informative; no filler. Despite length, it is clear and front-loaded with essential info (language requirement).

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

  Completeness5/5

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

  For a tool with 14 parameters and no output schema, the description covers all parameters, return types, and examples. It also provides critical notes (English-only, safety checker). No gaps remain given the complexity.

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

  Parameters5/5

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

  The schema has 0% description coverage (only titles), but the description compensates by explaining each parameter's purpose, format, and defaults (e.g., loras format, size format, duration constraints). This adds significant value beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool generates a video using WaveSpeed AI, specifying required inputs (image and prompt). The verb 'generate' and resource 'video' are precise, and the name 'generate_video' aligns. Siblings are different (image-to-image, text-to-image), so purpose is well-distinguished.

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: prompts must be English, duration must be 5 or 10, and includes examples. However, it does not explicitly compare with sibling tools or state when not to use this tool (e.g., for text-only video generation without an image).

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