Server Quality Checklist

Tool Scores

• list_tasksC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, pagination, ordering, or any limitations. It only states basic functionality.

  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 a single concise sentence that front-loads the main action. No wasted words, though it could be slightly more structured.

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

  Completeness3/5

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

  For a simple list tool with one optional parameter and no output schema, the description is adequate but lacks details like returned fields, ordering, or pagination. It is minimally sufficient.

  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?

  The schema coverage is 100% with one parameter, and the description merely restates the filtering capability. The parameter description in schema is already clear ('filter by status'), so no additional meaning is added.

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

  Purpose4/5

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

  The description clearly states the verb 'list' and resource 'tasks' (image generation tasks), and mentions filtering by status. It distinguishes from sibling tools like generate_image (creation) and check_task (checking a specific task).

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives like check_task. The description implies listing all tasks but does not specify context or exclusions, leaving the agent to infer usage.

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

• generate_videoA
  3.5/5.0
  Behavior3/5

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

  Discloses async polling, saving to projectDir, and support for text/image-to-video. With no annotations, this carries full burden, but it omits details like return value (task ID?), error handling, authentication, or failure behavior, leaving 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?

  Description is a single concise paragraph that front-loads the main purpose, then details, then user guidance. It is appropriately sized but could be more structured (e.g., bullet points) for clarity.

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

  Completeness3/5

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

  Covers async nature, output path, modes, and user interaction. However, with 8 parameters, no output schema, and no annotations, it misses critical details like what the tool returns (task reference) and how to handle errors or check progress, making it only moderately complete.

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

  Parameters4/5

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

  Schema covers all 8 parameters with descriptions (100% coverage). The description adds practical tips for projectDir (use pwd) and fileName (meaningful English name), and clarifies outputSubdir defaults and usage, enhancing usability beyond schema.

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

  Purpose4/5

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

  The description clearly states it submits an asynchronous video generation task that saves to local directory, and mentions text-to-video and image-to-video modes. However, it doesn't explicitly differentiate from sibling tools like generate_image, but the unique verb 'generate_video' and async nature suffice.

  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?

  Provides guidance on the async nature and instructs the agent to ask the user about tracking progress. However, it lacks explicit when-to-use vs. alternatives (e.g., generate_image) and does not mention limitations or prerequisites.

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

• check_taskA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description discloses the tool is a read-only query operation and that results include a local image path. It does not mention side effects, rate limits, or authentication, but is fairly transparent for a query tool.

  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 concise with three short sentences, front-loading the purpose. No wasted words.

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

  Completeness3/5

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

  The description lacks detail on response structure for in-progress states or errors. Since there is no output schema, more completeness would be helpful.

  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?

  Schema coverage is 100% for the single parameter, so the description provides minimal added value beyond the schema. It does not elaborate on the task ID origin or format.

  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 queries the status and results of an image generation task. It distinguishes from siblings that generate or list tasks, making it easy to select.

  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 mentions that background worker auto-polls, so no manual polling is needed, which implies when to use this tool for checking results. However, it does not explicitly state when not to use it or provide alternatives.

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

• generate_turnaroundA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry behavioral disclosure. It discloses async nature, output directory, and consistency requirement, but omits details like error handling, authentication needs, or what constitutes success/failure.

  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?

  Two sentences front-load the purpose and output specifics. The second sentence adds crucial user-interaction guidance. No extraneous information.

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

  Completeness4/5

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

  For an async task with no output schema, the description should explain the return value (presumably a task ID). It does not. However, it covers input, output directory, and user interaction, making it mostly complete.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the schema already documents parameters. The description adds value by explaining the default subfolder, the purpose of fileName (meaningful name), and how to obtain projectDir (via pwd).

  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 verb (submit async task), resource (turnaround view generation), and output (2x2 grid with front/side/back/action). It distinguishes from sibling tools like generate_image (single image) and generate_video by specifying multi-view output.

  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 instruction for the agent to ask the user about tracking behavior, which aids in correct usage. Does not fully detail when to choose this over siblings, but the purpose differentiation 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.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the async nature, polling mechanism, save location, and typical generation time, which is sufficient for a generation tool.

  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 fairly concise and well-structured, starting with the core function, then detailing saving directory, then typical duration, and ending with user interaction. The user question could be omitted for brevity, but it adds clarity for usage.

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

  Completeness3/5

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

  While the description covers the save path, naming, and async behavior, it does not mention the return value (likely a task ID) or error handling. Given no output schema, this is a gap that reduces completeness.

  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 coverage is 100%, but the description adds significant value beyond schema descriptions: it explains how to obtain projectDir, naming conventions, auto-suffix for multiple images, and subdirectory customization. This meets the high bar.

  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 it submits an async image generation task and specifies where images are saved. It is distinct from siblings like check_task and generate_video, as it focuses on generating images.

  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 explains that the task is async and returns immediately, and advises asking the user about progress tracking. It does not explicitly state when not to use this tool, but provides good context for decision-making.

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