Server Quality Checklist

Tool Scores

• images_to_pptxC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full transparency responsibility. It only states that images are converted to PPTX, but does not disclose whether outputPath is overwritten, how image order is handled, supported image formats, or error behavior. This leaves significant behavioral uncertainty.

  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, clear sentence with no redundant words. It is front-loaded and easy to parse, earning its place.

  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 a simple schema but no annotations or output schema. The description covers only the core conversion function and lacks context about when to use it, how it differs from alternatives (especially images_to_pdf), and what happens to the output. This makes it minimally complete but insufficient for complex decision-making.

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

  Parameters2/5

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

  The schema provides no descriptions for imagePaths or outputPath (0% coverage). The description mentions 'multiple images' and 'PPTX file', which loosely maps to the parameters, but it does not explicitly define what imagePaths and outputPath represent (e.g., file paths) or explain their roles. Given the low schema coverage, the description insufficiently compensates.

  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 '将多张图片转换为 PowerPoint (PPTX) 文件' clearly states the tool converts multiple images into a PPTX file, specifying a specific verb, input, and output format. It is distinguishable from siblings by the PPTX format, though it does not explicitly contrast with the similar images_to_pdf tool.

  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 is provided on when to use this tool versus alternatives like images_to_pdf. The description only states the conversion action without any context, prerequisites, or exclusions, leaving the agent to infer usage based on the output format.

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

• generate_image_with_shared_contextB
  3.4/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 disclosing behavior. It only mentions high-level capabilities ('supports all four models', 'supports specifying resolution') and style consistency but omits critical behavioral details like what the tool returns, whether it saves files, error handling, rate/concurrency implications, or side effects. This is insufficient for an agent to safely invoke the 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 a single, concise line with an emoji and bold text. Every segment adds value: purpose, style consistency, target use cases, model support, and resolution support. There is no fluff or redundancy, making it highly efficient.

  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?

  This is a complex batch tool with 7 parameters, 2 required, and no output schema. The description gives high-level use cases but omits essential details about how the shared context is applied, how the requests array should be structured, what the output looks like, and potential side effects. For an agent to confidently use this tool, significantly more context is needed.

  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 baseline is 3. The description's mention of shared context and resolution aligns with the styleContext and resolution/image_size parameters, but it does not add new semantic meaning beyond what the schema already provides. No extra parameter guidance is given.

  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 '共享上下文批量生图' (shared-context batch image generation) and '保持风格一致性' (maintaining style consistency), specifying the action and distinguishing value proposition. It also gives concrete use cases (PPT, tutorials, card sets) that set it apart from generic batch generation. However, it does not explicitly name or contrast sibling tools like generate_image_batch, so it falls short of a full 5.

  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 usage context: suitable for series images such as PPT, tutorials, and card sets, implying the need for consistent style. It does not explicitly state when not to use this tool or mention alternatives, so it lacks the exclusion and alternative guidance needed for a 5. Still, the use-case framing is directly actionable.

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

• edit_image_nanoA
  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 full behavioral burden. It only lists features and makes an inaccurate claim of 'all four models' when the schema contains eight model enums. It does not disclose save behavior, overwrite risks, or output details.

  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, front-loaded sentence with no filler. Each clause adds a relevant capability, and it is appropriately sized for the tool's scope.

  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 10 parameters, no annotations, and no output schema, so the description must compensate. It fails to explain mode selection (single vs. batch), how to choose between imagePath/requests, or what the tool returns—leaving significant gaps for a complex 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 description coverage is 100%, so the structured fields already document every parameter. The description adds minimal meaning beyond naming feature areas like resolution and aspect ratio, which the schema already covers.

  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 edits images ('编辑图像') and specifies single or batch scope. It mentions key capabilities (all models, multi-reference, resolution/aspect ratio) that distinguish it from sibling generation or conversion 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?

  The description clearly implies editing existing images rather than generating new ones, and explicitly notes single/batch usage. However, it does not explicitly name alternatives or exclusions, so it falls short of full guidance.

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

• images_to_pdfA
  3.6/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 burden. It discloses a key behavioral trait: each image is placed on its own PDF page with 'perfect fill and no whitespace'. However, it does not mention potential side effects like overwriting existing files, page size, or aspect ratio handling.

  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 sentence with the key information, no fluff, and the action is front-loaded. Every clause serves a purpose, making it highly concise and well-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?

  Given the tool's simplicity, the description covers the core function but leaves gaps: parameter details are absent, and it does not mention behaviors like overwriting output or supported image formats. It's adequate but not comprehensive, especially with no annotations or output schema.

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

  Parameters2/5

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

  The input schema includes imagePaths and outputPath, but the description adds no explanation for these parameters. With 0% schema description coverage, the description should compensate, but it only names the conversion, leaving parameter semantics to be inferred from their self-explanatory names.

  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 'convert' and resource 'multiple images to PDF', with specific scope details 'one per page, perfectly filled without whitespace'. This distinguishes it from the sibling images_to_pptx by the output format (PDF vs PPTX).

  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 when a PDF output is needed, but it does not explicitly mention when to use this tool over the sibling images_to_pptx or any exclusions. It provides clear context but lacks alternative guidance, so it receives a 3.

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

• generate_image_batchA
  4.2/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 transparency burden. It discloses important behavioral traits: automatic fallback to MCP server directory on write failure, priority of saveToFilePath over outputDir, and default concurrency. It does not mention return format or error handling, but the disclosed behaviors are substantial.

  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 and front-loaded: the first sentence establishes the tool's purpose, the model list is compact, and the path rules are presented as a numbered list. Every sentence adds value with no fluff or redundancy.

  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 tool has 7 parameters with 100% schema coverage and no output schema, the description adequately enhances context with path priority and fallback rules. It does not explicitly state return values, but the output is implicitly file paths, and the description covers the critical behavioral aspects for a batch 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 description coverage is 100%, so the baseline is 3. The description adds some value by grouping models by quality/speed and explaining path fallback, but most parameter semantics are already present in the schema. No major compensatory additions exist.

  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 '批量生图（单张或多张，高并发）' – batch image generation (single or multiple, high concurrency). It also lists supported models and options, effectively distinguishing itself from sibling tools like edit_image_nano, images_to_pdf, and images_to_pptx.

  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 strong contextual cues: batch vs single, high concurrency, path priority rules, and fallback behavior. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a perfect 5.

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