Server Quality Checklist

Tool Scores

• generate_from_videoA
  3.7/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 mentions the 'flash model only' constraint and lists output types, but lacks details on authentication needs, rate limits, resource consumption, or what happens with different video lengths.

  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 provide essential information: the core function, constraint, and example outputs, with no redundant or verbose content.

  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 six parameters and no output schema, the description is somewhat sparse. It does not explain parameter interactions, output format, or best practices for complex video-to-image generation, leaving gaps for an agent to infer.

  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 67%, so the description adds minimal parameter insight beyond the schema. It reinforces that youtube_url must be public but does not clarify size, ratio, or prompt formatting beyond schema defaults.

  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 generates an image from a YouTube video URL, with specific examples like thumbnails, posters, infographics, and key-moment art, differentiating it from sibling tools like generate_image which likely handle general image generation.

  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 specifies the tool works only with public YouTube URLs and the flash model, providing clear context. However, it does not explicitly state when not to use it or recommend alternative tools for other scenarios.

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

• generate_icon_setA
  4/5.0
  Behavior4/5

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

  Discloses key behavioral trait: sequential chaining for style consistency. Also specifies file naming pattern. With no annotations, it covers essential generative behavior, though lacks details on failure handling or determinism.

  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?

  Three concise sentences with clear front-loading: main behavior, naming rule, then use cases. No wasted words.

  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?

  Covers core behavior (style consistency, naming) and use cases. Lacks detail on parameter effects, error handling, and output format (assumed images). Reasonably complete for a simple tool with 4 parameters and no output schema.

  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 50% with descriptions only for prompts and output_dir. Description adds naming convention (icon-shopping-cart.png) but doesn't explain size options (0.5K to 4K) or model differences (nano/flash/pro). Moderate added value beyond schema enums.

  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?

  Strong verb 'Generate' and resource 'set of style-consistent icons' clearly defined. Distinguishes from siblings like generate_image by emphasizing multi-turn chaining for consistency. Specific file naming convention and use cases provided.

  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?

  Implies usage contexts (app icon sets, UI glyphs, feature illustrations) but no explicit when-to-use vs alternatives like generate_image. No exclusion criteria or prerequisites stated.

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

• generate_storyA
  4/5.0
  Behavior4/5

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

  Without annotations, the description provides key behavioral details: saves numbered images to a directory and returns markdown with inline image paths. This adds value beyond the schema, though it omits potential side effects like overwriting files.

  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 sentences efficiently convey the core function, examples, output format, and side effect. No redundancy; front-loaded with the primary action.

  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 tool with no output schema, the description explains the return value (markdown with image paths) and side effect (saved images). It lacks details on image count or ordering but is adequate for typical usage.

  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 baseline is 3. The description adds example values for prompt but does not elaborate on other parameters beyond the schema. Overall, marginal added value.

  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 generates interleaved text and images from a single prompt, listing specific use cases like storyboards and comics. This distinguishes it from sibling tools that handle single images or icons.

  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 through examples but does not explicitly state when to use this tool versus alternatives or provide exclusions. Sibling context is absent from the description.

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

• generate_imageA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses model behavior differences, output format dependency on file extension, interaction_id for iteration, and search grounding. It does not cover failure modes or authentication, but key behavioral aspects are covered.

  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?

  Description is front-loaded with purpose and model overview. It uses bullet-like sentences for clarity. Some redundancy (e.g., repeating model capabilities in both first sentence and parameter list) could be trimmed, but overall efficient for the amount of information.

  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?

  Covers models, output, search, and preview. However, no output schema exists, and the description does not detail the full return value (e.g., whether image is returned as URL or base64, or the structure of interaction_id). The preview parameter is mentioned but response format incomplete.

  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?

  Schema coverage is 100%, giving baseline 3. The description adds value by explaining model nuances (nano=fast/1K, flash=best/4K, pro=professional/thinking), output format selection via extension, and search capability. Prompt tips further enhance parameter understanding beyond 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?

  The description clearly states 'Generate a single image' with specific model names (Nano Banana) and explicitly lists use cases (illustrations, product photography, etc.). It differentiates this tool from siblings like edit_image and generate_icon_set by focusing on single image generation.

  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?

  Provides explicit guidance on when to use each model (nano for fast, flash for best all-around, pro for professional) and when to enable search. However, it does not explicitly state when not to use this tool (e.g., for generating multiple images at once), though sibling names imply alternatives.

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

• edit_imageA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses behavioral traits: returns a new interaction_id for iteration, limits for reference_images (up to 14, with model-specific constraints), and that the output format is determined by file extension. It does not mention destructive behavior but editing images typically implies modification.

  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 moderately concise and well-structured. It front-loads the core purpose, then explains two distinct usage modes, and ends with a prompt tip. Every sentence adds value, though it could be slightly tighter.

  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 10 parameters and no output schema, the description covers key behaviors: iteration flow, reference image limits, and prompt style. It could mention that output size defaults to 1K and model defaults to flash, but these are in the schema. Overall, it provides sufficient context for an agent to use the tool effectively.

  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?

  Schema coverage is 90%, so baseline is 3. The description adds meaning beyond schema by explaining the recommended workflow (previous_interaction_id) and specific use cases for reference_images. It also provides a prompt tip that enhances understanding of how to craft effective prompts.

  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 starts with 'Edit or iterate on an image with a follow-up prompt,' clearly stating the core function. It distinguishes from siblings like generate_image (which likely generates from scratch) by emphasizing iterative editing and providing specific use cases like virtual try-on and product placement.

  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 explicit guidance on when to use each mode: use previous_interaction_id for multi-turn editing (recommended) or reference_images for specific tasks. It also includes a prompt tip. However, it does not explicitly state when not to use this tool versus alternatives.

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