Server Quality Checklist

Tool Scores

• generate_image_setB
  3.3/5.0
  Behavior3/5

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

  The description discloses a useful behavioral trait: the operation is implemented through multiple underlying calls. However, with no annotations provided, it fails to mention potential side effects, failure modes, cost, rate limits, or how results are aggregated/returned.

  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 extremely concise with two sentences, each adding value. It is front-loaded but lacks structural organization; a bit more context would make it more useful.

  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?

  For a tool with 6 parameters, no output schema, and no annotations, this description is insufficient. It does not explain return value handling, batching error behavior, or relationships to sibling tools, leaving significant gaps.

  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 the schema fully documents all six parameters. The description adds no additional parameter-level detail beyond what the schema already provides.

  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's purpose: batch-generating multiple content-related images. It distinguishes from sibling tools by emphasizing 'multiple' and 'content-related', though it does not explicitly name alternatives.

  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 generation of related images, but provides no explicit guidance on when to choose this tool versus generate_image or image_to_image. No exclusions, prerequisites, or scenario examples are given.

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

• image_to_imageB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core function and does not mention constraints like URL accessibility, model compatibility, output format behavior, or any rate/cost considerations. The schema provides some parameter details but the description itself adds little behavioral context.

  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 extremely concise, using a single short sentence after the initial '图生图' label. It is front-loaded and wastes few words, though it may be overly terse given the tool's complexity.

  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?

  Given the tool has 6 parameters, no output schema, no annotations, and sibling tools for comparison, the description is too minimal to be fully contextually complete. It lacks guidance on expected outputs, when to choose this tool, or how the generation behaves with multiple reference images.

  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 description coverage is 100%, so the schema adequately documents all parameters. The description adds no semantic value beyond the schema, only reinforcing the 'reference images' concept already captured by image_urls. This meets the baseline but does not exceed it.

  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?

  Description clearly states the tool's action: '图生图。基于参考图片生成新图片' (image-to-image, generate a new image based on reference images). It specifies both the resource (reference images) and the verb (generate), and the reference-image basis distinguishes it from sibling tools like generate_image.

  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?

  Usage is implied: it is for generating images from reference images. However, there is no explicit guidance on when to use this tool versus alternatives such as generate_image or generate_image_set, and no mention of when not to use it.

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

• generate_imageA
  3.6/5.0
  Behavior2/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 of behavioral disclosure. It only states that the tool generates an image from text, but does not disclose output format, default watermark behavior, model behavior, or any side effects. Minimal behavioral detail beyond the tool's name.

  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 extremely concise, consisting of two short sentences. The second sentence adds useful detail (text input and single image output) rather than repeating the first. No wasted words or filler.

  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?

  The tool has 7 parameters, no output schema, and no annotations, yet the description provides no guidance on result format, how to configure size or model, or when to prefer sibling tools. It only explains the basic operation, which is insufficient for a tool with this many configurable options.

  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 input schema has 100% description coverage with per-parameter explanations, so the baseline is 3. The description adds no parameter-specific guidance beyond indicating that a text prompt is used, which the schema already documents.

  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 a specific verb+resource: '生成图片' (generate image) and explicitly says '使用文字描述生成一张图片' (use text description to generate one image). This differentiates the tool from siblings like image_to_image by specifying text input, and from generate_image_set by specifying a single 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 context that this tool is for text-to-image generation from a text prompt, implying it should be used when the user has a textual description and wants a single image. However, it does not explicitly name alternatives or advertise when not to use this tool.

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

• list_modelsA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It only restates the function implied by the name and does not disclose behavioral traits such as read-only safety, output format, side effects, or any prerequisites. It adds little beyond the obvious.

  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 a single concise phrase with no wasted words. It is appropriately sized for a parameterless query tool.

  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?

  Given the tool's simplicity (no parameters, no annotations, no output schema), the description gives a high-level summary but lacks detail about the exact return structure or how the model list connects to sibling tools. It is adequate but not complete for an agent needing to use the output.

  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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and there is no schema to compensate for, making this baseline 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 retrieves a list of supported models with feature descriptions, using a specific verb ('获取') and resource ('支持的模型列表和功能说明'). This distinguishes it from sibling tools that generate or transform images.

  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?

  Usage context is implied: it's a query tool that likely provides model selection info for the sibling generation tools. However, there is no explicit statement about when to use it or how it relates to alternatives, missing a clear when-to-use/when-not-to-use directive.

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