Server Quality Checklist

Tool Scores

• generate_blog_coverA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It successfully documents the multi-step pipeline (generation, conversion, upload) and external dependencies, but fails to disclose critical behavioral traits like whether the CDN upload is idempotent, what happens on naming collisions, or what the tool returns (URL, path, or binary).

  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, efficiently structured sentence that front-loads the action and logically flows through the processing pipeline (generate → convert → upload). Every word serves a purpose with no redundancy.

  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 absence of both annotations and output schema, the description should explain return values and side effects (e.g., 'returns public CDN URL'). It adequately covers the input workflow but leaves critical gaps regarding the operation's output and mutation characteristics.

  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, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though it implicitly reinforces that 'slug' relates to blog posts through the workflow context. No additional parameter constraints or format details are provided.

  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 explicitly states the specific verb (Generate), resource (blog cover image), AI technology (Google Gemini), format conversion (WebP), and destination (Qiniu CDN). This specificity effectively distinguishes it from the generic 'generate_image' and single-purpose 'upload_image' siblings.

  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?

  While the specificity of 'blog cover' implies the intended use case, the description does not explicitly state when to choose this tool over 'generate_image' or 'upload_image', nor does it mention prerequisites like requiring valid CDN credentials or prompt engineering best practices.

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

• upload_imageA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the WebP conversion side effect and CDN URL return, but omits mutation safety details (overwrite behavior, idempotency, whether local files are deleted), authentication requirements, or error conditions.

  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?

  Single sentence of 15 words with zero waste. Front-loaded with the core action, includes all key elements (source types, destination, transformation, output), and avoids filler words or redundant phrases.

  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?

  For a 3-parameter upload tool with no output schema, the description adequately covers the essential contract: input handling, processing side effects, and return value. Minor gaps remain regarding error handling, overwrite semantics, and authentication, but the core functionality is well-documented.

  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%, establishing a baseline of 3. The description adds minimal parameter-specific context beyond the schema, though 'local or remote' reinforces the source parameter's dual-purpose nature. No additional syntax guidance or format examples are provided.

  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 specific action (upload), resource type (image), destination (Qiniu CDN), transformation (convert to WebP), and return value (CDN URL). It effectively distinguishes from siblings generate_image and generate_blog_cover by emphasizing 'upload' versus generation.

  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?

  While the verb 'upload' implies usage for existing images versus generating new ones, the description lacks explicit when-to-use guidance or named alternatives. It does not clarify whether to use this versus the generate_* siblings when both might apply.

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

• generate_imageA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden and succeeds in revealing the AI provider (Google Gemini), format conversion (WebP), storage destination (Qiniu CDN), and return value type (CDN URL). It lacks rate limits, authentication requirements, or error handling details, but covers the essential behavioral chain adequately.

  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, efficiently structured sentence that front-loads the action sequence. Every clause provides distinct value: AI provider identification, format specification, storage destination, and return type. Zero redundancy or filler content.

  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?

  For a 3-parameter tool with no output schema, the description adequately covers the full operation lifecycle from generation through delivery. It mentions the return value (CDN URL) despite lacking a formal output schema. Minor gap: no mention of error conditions, latency expectations, or image dimension constraints.

  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?

  Input schema has 100% description coverage, establishing a baseline of 3. The description focuses on the operational workflow rather than adding parameter-specific semantics (e.g., prompt length constraints, slug format rules, valid path values). No additional parameter context is provided beyond the schema definitions.

  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 specific verbs (generate, convert, upload, return) and clearly identifies the resource (image), AI provider (Google Gemini), format (WebP), and destination (Qiniu CDN). It distinguishes from sibling 'upload_image' by including generation capability and from 'generate_blog_cover' by implying general-purpose use through the absence of blog-specific constraints.

  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?

  While the description implies usage through its specific workflow (generation + conversion + upload), it lacks explicit guidance on when to choose this over 'upload_image' (for existing files) or 'generate_blog_cover' (for specific blog formatting). The agent must infer the appropriate use case from the described behavior chain.

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