Server Quality Checklist

Tool Scores

• get_video_task_resultA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description fully bears the load. It discloses polling behavior, expected duration (1-3 minutes), and appropriate agent actions. Does not mention potential failures beyond statuses.

  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?

  Concise, well-structured with clear sections including critical instructions. Every sentence adds value, no redundancy.

  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 the output schema exists (not provided but indicated), the description sufficiently covers the polling loop and status handling. Complete for a query tool with one parameter.

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

  Parameters3/5

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

  Only one parameter (task_id) which is well-described in the schema itself ('Task ID from generate_video'). The description adds no additional meaning beyond the schema's property description, so baseline of 3 applies.

  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?

  Clearly states it queries the status of a video generation task using the Task ID from generate_video. Distinguishes from sibling tools generate_image and generate_video by focusing on result retrieval.

  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?

  Provides explicit instructions on when to call this tool (after generate_video) and how to handle different statuses (ordered/running vs succeeded). Lacks explicit 'when not to use' but is clear enough.

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

• generate_imageA
  4.7/5.0
  Behavior4/5

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

  No annotations exist, so the description carries full burden. It discloses critical parameter behaviors (e.g., 'model' should be omitted unless custom endpoint) and mode-specific requirements. However, it does not mention rate limits, authentication, or idempotency, leaving some gaps.

  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 sections for critical instructions and capabilities. It is efficient but slightly verbose in the instructions section; however, every sentence serves a purpose.

  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 the tool's complexity (two modes, multiple constraints), the description covers essential usage details. The presence of an output schema reduces the need to describe return values, making the description complete.

  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 description adds significant context beyond the input schema, such as the prohibition of 'ratio' and the rule for 'model'. It also explains the relationship between parameters for different modes, enhancing understanding of parameter usage.

  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 images using a specific API. It lists two capabilities (text-to-image and image-to-image), and sibling tools ('generate_video', 'get_video_task_result') are distinct, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit instructions: use 'size' parameter only, avoid 'ratio'/'width'/'height', and pass custom endpoint IDs to 'model'. It also explains when to use each mode based on provided parameters, offering clear guidance.

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

• generate_videoA
  5/5.0
  Behavior5/5

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

  Without annotations, the description fully discloses behavior: asynchronous (returns Task ID, needs polling), default values, accepted values for ratio and resolution, automatic role assignment for images, and model-specific limitations (e.g., generate_audio only for Pro models).

  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?

  Well-structured: starts with main purpose, then critical instructions in bold, followed by capabilities. Each sentence adds value without redundancy. Uses formatting for emphasis and lists for clarity.

  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?

  Fully covers all aspects needed for correct usage: explains the asynchronous workflow, all parameter constraints, mode-specific behaviors, and edge cases (e.g., seed for reproducibility, watermark option). With an output schema present, the description appropriately focuses on input semantics and process.

  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?

  Adds critical meaning beyond the input schema: clarifies that 'model' should be omitted unless user specifies an Endpoint ID, that 'ratio' must not use 'size' parameters, and explains the roles of image_urls, video_urls, and audio_urls for different modes. Enumerates accepted values for ratio explicitly.

  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?

  Explicitly states "Create a video generation task" and distinguishes from sibling tools by noting that this tool only submits the task and returns a Task ID, while `get_video_task_result` must be polled later.

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

  Usage Guidelines5/5

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

  Provides clear when-to-use instructions: only for submitting tasks, not for retrieving results. Gives detailed do's and don'ts (e.g., use 'ratio' not 'size', leave 'model' empty unless custom endpoint). Lists three capability modes with their parameter requirements.

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