Server Quality Checklist

Tool Scores

• generate_imageA
  3.7/5.0
  Behavior4/5

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

  Annotations already indicate a non-read-only, non-idempotent operation, and the description adds useful behavioral context: it calls a remote Agnes API and supports both URL and base64 output. It does not contradict any annotation, though it could mention side effects like cost or latency.

  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 compact sentences with no filler. The main action and model are front-loaded, and the supporting capabilities are listed efficiently.

  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 the core use case and remote API dependency, and an output schema exists to define return values. Still, with six parameters and no schema-level descriptions, the description leaves gaps around image input format, size meaning, and model choices, making it slightly incomplete for fully confident invocation.

  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 0%, so the description must compensate. It partially does by implying prompt for text-to-image, images for reference input, and output for URL/base64. However, it does not clarify size, ratio, or model semantics, leaving the agent to infer from enums and 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 states a clear verb and resource: '使用 Agnes 模型生成一张图片' (generate an image with the Agnes model), and adds concrete behavior: text-to-image or reference-image input, returning URL or base64. The singular '一张图片' also helps distinguish from the sibling generate_images.

  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?

  The description explains what the tool can do but gives no guidance on when to choose it over siblings like generate_images, download_image, or validate_image. There is no mention of when not to use it, prerequisites, or alternative routing.

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

• generate_imagesA
  4/5.0
  Behavior5/5

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

  描述补充了注释未覆盖的关键行为：按顺序执行、默认遇错停止、可配置继续处理并返回成功/失败/跳过统计。这些信息对调用方非常重要，且与 openWorldHint=true 等注释一致，无矛盾。

  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?

  描述为单句话，信息密度高且无冗余，先说明核心动作，再补充错误处理与返回统计。虽然紧凑，但结构不算条理化，较长的单句可能稍显拥塞。

  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?

  输出 schema 已提供返回统计的结构，注释也标记了副作用特性，描述则提供了调用策略（顺序、错误处理）。但 schema 覆盖率 0% 时，描述未能点明 items 参数的基础要求（如每项需 prompt 和 size），调用 agent 仍需完全依赖 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?

  Schema 描述覆盖率为 0%，描述需要补偿参数含义，但仅间接提到了 continueOnError（'可选择继续处理'），未解释 items 数组的结构、prompt 和 size 要求，也未提及 concurrency 固定为 1。描述几乎没有为参数提供超出 schema 的额外含义。

  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?

  描述使用明确动词'批量调用 Agnes 生成图片'，指明资源与动作，并强调'批量'，与兄弟工具 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?

  描述通过'批量'一词隐含适用于一次生成多张图片的场景，但未明确说明何时应改用 generate_image 或与其他兄弟工具的关系。没有给出 when-not-to-use 或替代工具的指引。

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

• validate_imageA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context beyond those: no network access, no file modification, and validation of file size and specific image formats. This gives an agent useful constraints without contradicting the annotations.

  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?

  A single sentence carries the action, scope, validation criteria, and side-effect exclusions with no filler. All key information is front-loaded and every clause earns its place.

  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 output schema covers return-value expectations, and annotations cover safety and idempotency. The description completes the picture with path scoping, format restrictions, and explicit no-network/no-modification guarantees. It is concise but sufficient for a simple validation 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 0%, so the description must compensate. It does map the path parameter to a current-working-directory relative path and implies maxBytes through file-size validation, but it does not explicitly name the parameters or explain defaults and bounds. This is adequate but not fully explicit.

  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 names a specific action (读取/校验) and resource (local image file), and further scopes it to relative paths in the current working directory plus specific formats (PNG, JPEG, GIF, WebP). It clearly distinguishes itself from siblings like generate_image and download_image, which create or fetch images rather than validating existing local files.

  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 gives clear context for when to use the tool: local files, relative paths, and explicit statements that it does not access the network or modify files. However, it does not explicitly name sibling alternatives or state when to prefer those instead, so the usage guidance is clear but not fully exclusionary.

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

• download_imageA
  4.4/5.0
  Behavior5/5

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

  Beyond the annotations, the description discloses concrete safety behaviors: it rejects intranet addresses, path traversal, links/symlinks, and existing-file overwrites. These details meaningfully shape how an agent can expect the tool to behave.

  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?

  A single, well-structured sentence with no filler. The primary action is stated first, followed by a clear semicolon-separated list of rejection conditions.

  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 covers the core behavior, security constraints, and path semantics well, and an output schema exists to document return values. The only notable omission is behavior related to maxBytes, which is less critical because the parameter schema provides defaults and bounds.

  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 0%, and the description partially compensates by clarifying that url must be a public HTTPS address and outputPath is a relative path. It does not explain maxBytes or what happens when the limit is exceeded, though the schema's default and maximum provide partial guidance.

  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 names a specific verb ('download') and resource ('image') and precisely defines the target location as a relative path under the current working directory. It also distances itself from siblings by focusing on fetching an existing image rather than generating or validating one.

  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?

  It gives clear context: use it only for HTTPS public addresses and relative output paths, and it lists rejected inputs such as intranet addresses and path traversal. It does not explicitly name sibling alternatives as choices, but the download-vs-generate/validate distinction is implicit.

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