Server Quality Checklist

Tool Scores

• gemini_generate_imageB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate non-readOnly and non-destructive. The description adds that the tool returns an embedded image block and optionally saves to disk. However, it does not disclose potential side effects like cost or latency. The mention of 'Gemini Nano Banana' model might be outdated but does not contradict 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?

  The description is well-structured with Args, Returns, and Examples sections. Every sentence adds value, and the main purpose is front-loaded. No redundant or unnecessary text.

  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?

  Despite having 5 parameters and no output schema, the description omits the image_size parameter, leading to incomplete parameter documentation. It also does not explain return values beyond mentioning an embedded image block. For a tool with moderate complexity, this is a notable gap.

  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 covers all parameters with descriptions (100% coverage). The description adds value by providing examples and repeating key parameter info in a more readable format. However, it omits the image_size parameter entirely, missing a chance to add context beyond the schema.

  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 it generates an image from a text prompt, specifying the model. It implicitly distinguishes from siblings like edit_image or upload_image by focusing on generation, but does not explicitly contrast them, preventing a top score.

  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 on when to use this tool vs alternatives like gemini_edit_image. The description only states what it does, not when it is appropriate or when not to use it.

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

• gemini_batch_statusA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, non-destructive. The description adds return fields (state, output_file, stats, timing), enriching behavioral understanding beyond annotations.

  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?

  Front-loaded with purpose, followed by parameter and return details. Bullet points aid readability. Could be more concise but efficient overall.

  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?

  No output schema, so description carries responsibility. It lists state enum values, output file reference, stats, and timing. Adequate for a status check 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 coverage is 100% so baseline is 3. The description repeats the parameter info with an example, adding minor value but no significant new meaning.

  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 'Check the status' and specific resource 'batch image generation job'. Distinguished from sibling gemini_batch_results and gemini_batch_submit by focusing on status.

  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?

  Implied usage: check status after submission. No explicit when-not or alternatives, but sibling names provide context. The description itself lacks usage guidance beyond purpose.

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

• gemini_batch_resultsA
  4/5.0
  Behavior4/5

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

  The description discloses the full sequence of operations (checks status, retrieves JSONL, decodes, saves) and returns errors. This adds context beyond annotations (which only indicate not read-only, not idempotent). No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a lead sentence and clear sections, but the Args block is redundant with the schema, adding unnecessary length. Could be more concise.

  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 two parameters and no output schema, the description explains the process and return value (list of paths and errors). It is sufficiently complete, though missing details like file overwrite behavior or error types.

  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%, and the description repeats the schema descriptions verbatim without adding new semantic context (e.g., format, constraints). Baseline score of 3 is appropriate as the schema already documents both parameters.

  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 strong action verbs ('Download and save') and specifies the resource ('images from a completed batch job'). It clearly distinguishes from sibling tools like gemini_batch_status, gemini_batch_submit, and image editing/generation 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 implies usage after a batch is complete and details the process (check status, retrieve output, decode, save). However, it does not explicitly state when not to use or suggest alternative tools.

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

• gemini_upload_imageA
  4.5/5.0
  Behavior4/5

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

  Adds that files persist for 48 hours and return value is a list of URIs. Annotations don't contradict (readOnlyHint=false matches write operation). No mention of rate limits or failure modes, but context is good.

  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?

  Very concise: three sentences for purpose/usage, then args/returns in structured format. No superfluous text.

  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 single parameter and no nested objects, the description fully explains input, behavior, and output. No output schema needed due to clear description.

  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 covers 100% of parameters, and description provides an example of the comma-separated path format, which adds practical guidance beyond the 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 the tool uploads images to Gemini Files API and returns file URIs. It distinguishes from siblings by explicitly mentioning its use before gemini_batch_submit.

  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 says 'Use this to pre-upload reference images before calling gemini_batch_submit' and explains benefit of avoiding base64 encoding. Lacks when-not-to-use or alternatives, but sufficient.

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

• gemini_batch_submitA
  4.7/5.0
  Behavior4/5

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

  The description discloses async processing, file upload steps, and return of batch ID. Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior. However, it could mention failure handling or rate limits, but overall adds good context beyond annotations.

  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 well-structured with clear sections (args, returns) and uses concise language. It is not excessively long, though some redundancy exists (e.g., listing fields already in schema). Overall efficient.

  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 5 parameters, no output schema, the description fully covers the return value (batch ID, count, model), async nature, and tracking responsibility. It also relates to sibling tools (gemini_upload_image). Highly complete for an agent to use correctly.

  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?

  With 100% schema coverage, baseline is 3, but the description greatly enriches understanding: explains that 'requests' requires key, prompt, and optional fields; provides an example; distinguishes file_uris as faster; and clarifies image_size values. This goes well beyond the 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 starts with 'Submit a batch of image generation requests to the Gemini API at 50% reduced cost,' clearly stating the action and resource. It distinguishes from sibling tools by focusing on submission, while siblings handle results/status.

  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 explains when to use this tool (for cost-effective batch generation) and provides guidance on alternatives: recommends using file_uris over image_paths for speed, and notes that the caller is responsible for tracking the batch ID. This effectively sets context for usage.

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

• gemini_edit_imageA
  4.7/5.0
  Behavior5/5

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

  Annotations provide limited info (openWorldHint, etc.). Description adds significant behavioral context: powered by Gemini Nano Banana model, returns an embedded image block and optional disk save, and any accompanying text. No contradiction with 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?

  Well-structured with clear sections (description, args, returns, examples). Every sentence is informative, no redundancy, and it is appropriately concise for a multi-parameter tool.

  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?

  Despite missing output schema, the description explains the return format. All 7 parameters are documented in schema and description adds clarifying examples. Annotations provide additional hints. Complete for this complexity level.

  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 covers all parameters (100% coverage). Description adds value with examples, format details (e.g., comma-separated paths, JSON array for base64), and supported aspect ratios, enhancing schema documentation.

  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 it edits or transforms images using a text instruction. It specifies the resource (images) and action (edit/transform), distinguishing it from sibling tools like gemini_generate_image which creates new images.

  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 typical usage examples and states support for single or multiple images. It implicitly tells when to use (to edit images) but lacks explicit comparison to alternatives like gemini_generate_image for creation vs editing.

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