Server Quality Checklist

Tool Scores

• kie_create_taskB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It covers model selection, environment variable fallback, and automatic upload of local image paths. However, it omits that task creation is likely asynchronous and taskId is for polling, nor mentions any side effects, rate limits, or auth requirements.

  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?

  Three short, front-loaded sentences in Japanese. First sentence states purpose, second explains model switching, third clarifies image_input behavior. No redundant information; every sentence adds value.

  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 covers creation and model behavior but is missing critical context about asynchronous execution (taskId used for polling), error handling, and output format. Given the existence of kie_check_task, this omission is notable. The description is adequate but not fully 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?

  All 6 parameters have schema descriptions (100% coverage). The tool description adds extra value: explains model default logic based on image_input, and that image_input accepts URLs or local paths with auto-upload. This goes beyond the 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 the action ('create image generation task') and immediate return of taskId. It explains model switching logic. However, it does not explicitly differentiate from the sibling tool 'kie_create_tasks' (plural) which likely creates multiple tasks.

  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 versus alternatives (e.g., kie_create_tasks for batch operations, kie_check_task for status). The description only states what the tool does, not usage context or prerequisites.

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

• kie_check_taskA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses return behavior (image data on completion), optional file saving, and polling advice. Lacks error handling or rate limit info but is mostly transparent.

  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 efficient sentences with no waste. Front-loaded with primary action, compact and to the point.

  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 main behavior: check status, return image, optional save, retry hint. Missing details on return format (e.g., base64) and error handling. Adequate for simple tool but could be more complete.

  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%, so baseline is 3. The description adds context that save_to is used on completion and task_id is the identifier, but does not add significant detail beyond the 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 the tool checks the status of an image generation task and explains what happens on completion. It distinguishes from sibling tools which are plural or creation tools, though not explicitly.

  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 advises to wait and recheck if pending, which provides usage guidance. However, it does not specify when to use this tool over alternatives like kie_check_tasks or provide exclusions.

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

• kie_check_tasksA
  3.7/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses parallel checking and optional file saving, but does not specify return value format, blocking behavior, or potential side effects.

  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?

  Single sentence covering both core function and optional behavior. Efficient and to the point, though could be structured slightly better.

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

  Completeness2/5

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

  No output schema, and description does not explain return values (e.g., status objects). Missing guidance on how to interpret results, making it incomplete for a status-checking tool.

  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 provides 100% description coverage; description adds context that save_dir triggers file saving for completed images. Baseline 3 with minor added value.

  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 checks statuses of multiple image generation tasks in parallel, and optionally saves completed images. This distinguishes it from sibling 'kie_check_task' (singular).

  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?

  Implies use for checking multiple tasks in parallel vs singular sibling, and mentions optional file saving. Lacks explicit when/why to use or exclude, but context is clear.

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

• kie_create_tasksA
  3.7/5.0
  Behavior3/5

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

  Without annotations, the description discloses parallel creation, immediate return of taskIds, and model auto-switching. However, it omits details on error handling, partial failures, or asynchronous processing, leaving gaps in transparency.

  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 two concise sentences with the main action first and then a detail. Every sentence adds necessary information with no redundancy. It is well-structured for quick understanding.

  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?

  Given the absence of output schema and annotations, the description covers the core behavior well, but does not mention constraints like min/max tasks (1-10) or error scenarios. These are present in the schema but not in the description, so completeness is slightly diminished.

  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?

  The input schema already provides descriptions for all nested properties. The description adds value by explaining the model auto-selection logic and default model names, which go beyond the schema's enum or defaults. Since schema coverage is high, a score of 4 is appropriate.

  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 creates multiple image generation tasks in parallel and returns an array of task IDs. The verb 'create' and resource 'tasks' are specified. It distinguishes from the sibling 'kie_create_task' by indicating batch processing, but does not explicitly contrast.

  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 implies usage for batch image generation tasks, but does not explicitly state when to use this tool versus the singular counterpart 'kie_create_task' or other siblings. No exclusions or alternatives are mentioned.

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

• kie_upload_fileA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries the burden. It discloses that the tool returns a public download URL, has a 3-day storage period, and is a write operation. Missing details on authentication or rate limits, but sufficient for the tool's simplicity.

  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?

  Three well-structured sentences, front-loaded with the core action and then providing contextual guidance. No unnecessary words.

  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?

  The description explains the return value (public download URL) and storage duration, but does not specify exact output format or error conditions. Given no output schema, slightly more detail would be ideal, but it's still fairly complete.

  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% with descriptions for all 3 parameters. The tool description does not add per-parameter details, but the overall usage context is helpful. Baseline score of 3 is appropriate.

  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 uploads a local image and returns a download URL. It also distinguishes from the sibling kie_create_task by noting that auto-upload is the norm, making this tool for explicit pre-upload or reuse.

  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?

  Explicitly states when to use (pre-uploading, caching, reuse) and when not to (normally auto-uploaded by kie_create_task). Provides clear context for tool selection.

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