Server Quality Checklist

Tool Scores

• server_infoA
  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 carries the full burden. It describes the return values comprehensively (base_url, default_model, size_rules, recommended_sizes, capability_matrix, retry_policy) but does not explicitly state side effects, authentication requirements, or rate limits. It implies a read-only query, but lacks explicit safety declarations.

  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 concise sentences in Chinese plus a bulleted list of return fields. Every sentence adds value: the first states the purpose and usage, the second outlines the output. No fluff, front-loaded with the most important instruction.

  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 no parameters and an output schema exists (true), the description is fairly complete. It lists all return fields with brief descriptions. However, it could mention error cases or what happens if the server is unreachable, but for the typical use case, it is sufficient.

  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?

  Input schema has no parameters (empty object), so schema coverage is 100%. With 0 parameters, baseline is 4. The description adds value by explaining what the tool returns, though it doesn't need to explain parameter semantics since there are none.

  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 it is a diagnostic/capability query tool, explicitly specifying it should be called before any image generation tool. The verb '诊断 / 能力查询' (diagnostics/capability query) and the resource 'routing rules and size constraint matrix' make the purpose unambiguous. It also distinguishes from sibling tools which are image generation/editing tools.

  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?

  Explicitly instructs to call this tool before any image generation tool ('在调任何生图 tool 之前，先调一次此 tool 拿到完整路由规则与 size 约束矩阵'). This provides a clear usage context. While it doesn't mention when not to use it, it's a one-time prerequisite, so the guidance is sufficient.

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

• image_editA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully compensates. It discloses routing behavior (1K vs 2K paths), mask mechanics, 4K disablement, fallback logic, auto pro model selection, and common errors. This is highly transparent beyond the schema.

  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 quite long but well-structured with clear sections (WHAT, WHEN TO USE, 4K禁用, etc.) and bullet points. It uses front-loaded sections for quick scanning. Minor redundancy (e.g., mask details repeated in MASK section and param docs) prevents a perfect 5.

  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 (8 params, routing, mask, size constraints, fallback), the description is remarkably complete. It includes examples, common errors, and return value details. The presence of an output schema further reduces the burden, but the description still adds value.

  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, so the description must carry the full burden. It provides extensive details for all 8 parameters: prompt (specificity advice), image_path (supports multiple formats), mask_path (only 1K path, ignored at 2K), size (valid values, default, 4K disabled), model (auto pro), save_dir/basename (safety constraints), api_key (override locked base_url). This compensates completely.

  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 uses a specific verb ('edit') and clearly states it operates on a single image with a modification prompt. It distinguishes from sibling tools by explicitly listing when to use image_generate, image_batch_edit, and image_multi_reference instead.

  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 'when to use' and 'when not to use' guidance, including alternatives like image_generate for zero-creation and image_batch_edit for batch edits. It also details specific conditions (e.g., 4K disabled, mask only on 1K path).

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

• image_batch_editA
  5/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: concurrency strategy (5 for non-pro, serial with gap for pro), error handling (one failure does not affect others), size limitations, output naming, and that base_url is locked. 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 well-structured with clear sections ([WHAT], [WHEN TO USE], [并发策略], [LIMITS], Args, Returns, Examples). It is front-loaded with the core purpose and every sentence adds value. No unnecessary repetition.

  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 (6 parameters, output schema, sibling tools), the description covers all necessary aspects: purpose, usage guidelines, behavioral details, parameter semantics, return values, and examples. The output schema is described in the Returns section. No gaps.

  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%, but the description compensates excellently by explaining each parameter in the Args section, including examples, constraints (e.g., size only 1K, model values, save_dir must be under root), and the api_key override behavior.

  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 function: batch editing of N images with identical prompt and size, mapping N inputs to N outputs. It distinguishes from sibling tools by specifying that multi-reference style transfer is not supported and that single-image editing should use image_edit.

  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 (multiple images each needing the same modification), when not to use (multi-reference to generate one image), and provides alternative (image_edit for single image). Also includes batch size limits and concurrency strategy.

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

• image_generateA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It discloses many behavioral details: size compression logic (≤2.25MP compressed to ~1.57MP), pro/non-pro model selection based on size, concurrency behavior for n>1, save_dir security restrictions, and common errors with solutions. This fully informs the agent of the tool's behavior.

  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 well-structured with clear sections (WHAT, WHEN TO USE, SIZE, PROMPT, Args, Returns, Examples, Common errors). It is front-loaded with the most critical information. Despite its length, every section provides value and the format is easy to scan.

  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?

  The description covers all 7 parameters in detail and provides the output schema explicitly. It includes examples and common errors, making it highly complete for a complex tool with multiple parameters and behaviors.

  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%, but the description adds extensive meaning to each parameter. It explains size constraints (multiples of 8, resolution tiers, compression), prompt length and style advice, n concurrency, model auto-selection, save_dir restrictions, basename constraints, api_key usage, and fallback behaviors. This fully compensates for the lack of schema descriptions.

  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's purpose: text-to-image generation, rendering a prompt into images and saving locally. It explicitly distinguishes from siblings by providing when-to-use conditions for image_edit and image_multi_reference, making differentiation clear.

  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 includes an explicit 'WHEN TO USE' section that defines conditions for using this tool versus alternatives. It also offers guidance on selecting size, including recommending to call server_info() for recommended sizes, and advises on when to specify size explicitly vs letting MCP infer.

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

• image_multi_referenceA
  5/5.0
  Behavior5/5

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

  No annotations provided, so the description fully carries the burden. Discloses dual-path routing with fallback, 4K disablement due to CF 524, size limitations (1K stable, 2K unstable), and the actual output resolution during fallback. 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?

  Well-organized with sections: summary, what, when, limits, args, returns, examples, errors. Front-loaded with essential purpose. Every section adds value without redundancy. Concise for the complexity covered.

  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?

  Complex tool with multiple paths, fallback, and size behavior. Description covers all aspects: input requirements, process, output schema, error messages, and workarounds. With output schema present, return values are fully explained. No gaps.

  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%, but the 'Args' section thoroughly explains each parameter: prompt, image_paths (count constraint), size (recommendations and disallowed values), model, save_dir, basename, api_key. Includes defaults, examples, and common errors. Fully compensates for missing schema descriptions.

  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?

  Clear verb '多图融合参考' and resource '输出 1 张新图'. Distinguished from sibling 'image_batch_edit' by explaining N-in-1-out vs N-in-N-out. Purpose is immediately understandable.

  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?

  Explicit 'WHEN TO USE' section with specific user commands and a 'when not to use' section directing to alternative tools (image_batch_edit, image_edit, image_generate). Provides clear decision criteria.

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