Server Quality Checklist

Tool Scores

• nano_banana_2_temporaryC
  2.7/5.0
  Behavior2/5

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

  No annotations provided, so the description must fully disclose behavioral traits. It lacks information on side effects, idempotency, rate limits, or whether the tool is read-only or destructive. It mentions 'per-call' settings but does not explain how the tool behaves with those parameters.

  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 composed of two sentences, making it concise. However, the first sentence is awkwardly phrased ('Gemini generateContent-compatible exploration tool') and could be clearer. It front-loads key information but sacrifices some clarity.

  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?

  Given the tool's complexity (10 parameters, 6 required, output schema present), the description is insufficient. It does not explain the output, the role of save_path, or the significance of image parameters. Sibling tools with similar names add confusion. The description lacks completeness for effective agent use.

  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 description coverage is 0%. The description mentions only 4 of 10 parameters (api_key, base_url, model, timeout) without adding detail beyond their names. Critical parameters like prompt, save_path, version, and image settings are not explained, leaving the agent with insufficient meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it's a temporary exploration tool compatible with Gemini generateContent, and lists key parameters. However, the verb 'exploration' is vague and does not clearly state a specific action like 'generate' or 'create content'. It distinguishes from siblings by being 'temporary' but does not fully clarify its core purpose.

  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 it is for testing with unknown providers via per-call settings, but does not explicitly state when to use this tool versus the official counterparts (nano_banana_2_official, gpt_image_2_official). No guidance on when not to use it or specific contexts.

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

• list_image_tools_catalog_toolC
  2.8/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 burden for behavioral disclosure. It only says 'list', implying read-only, but omits details like authentication requirements, rate limits, or what constitutes 'effective config'. Minimal transparency.

  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 with no extraneous content. Front-loaded and efficient, every word earns its place.

  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?

  With an output schema present, return values need not be detailed. However, given simple structure (1 parameter) and sibling tools, the description lacks context on use cases, e.g., when to use this vs list_image_presets_tool. Adequate but incomplete.

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

  Parameters1/5

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

  Despite 0% schema description coverage for the main property 'version', the description does not mention the parameter at all. The $defs description is present but not tied to the tool's purpose. The tool fails to clarify how the version parameter affects the listing.

  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?

  Description states 'List image tool defaults and effective config', which clearly identifies the action and resource. It distinguishes from siblings by focusing on defaults/config, but lacks explicit differentiation from list_image_presets_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 on when to use this tool versus alternatives like list_image_presets_tool or other image tools. The description does not provide use cases or exclusions.

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

• nano_banana_2_officialC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description explains preset ownership, override behavior, and enum usage. However, it omits details like authentication requirements, error responses, or side effects beyond invalid sizes.

  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?

  Six sentences effectively convey the main purpose and key behavioral notes without excessive verbosity. The primary function is front-loaded.

  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?

  Given the tool's complexity (12 parameters, no schema descriptions), the description is insufficient. It covers preset semantics and enum usage but neglects many parameters, error handling, and return values, even with an output schema present.

  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?

  With 0% schema description coverage, the description only partially compensates by explaining preset, api_key, image_size, and aspect_ratio relationships. The other 8 parameters lack any added meaning.

  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 or edits images via a Gemini compatible gateway. It provides a specific verb and resource, though it does not explicitly distinguish from sibling tools like gpt_image_2_official.

  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 versus alternatives. The description focuses on preset behavior but lacks explicit 'when-not' or alternative tool references.

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

• list_image_presets_toolB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It only states what is listed but omits behavioral traits such as idempotency, read-only nature, authentication needs, or result characteristics (e.g., pagination).

  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 that conveys the core action and resource without any superfluous words.

  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 low complexity (1 required parameter, no nested objects) and the presence of an output schema, the description is minimally adequate but lacks details on behavior (e.g., sorting, filtering, response format) and does not compensate for missing annotations.

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

  Parameters1/5

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

  Schema description coverage is 0%, yet the description adds no information about the required 'version' parameter. The parameter's role and usage are entirely unexplained beyond the schema's enum definition.

  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 'list' and the resource 'registered presets', and specifies the attributes included (bound tool, base URL, default model). This distinguishes it effectively from sibling tools like list_image_tools_catalog_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, and there is no mention of prerequisites or context. The description lacks explicit usage context.

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

• gpt_image_2_temporaryB
  3.4/5.0
  Behavior3/5

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

  States 'sends only conservative fields by default', partially disclosing behavior. No annotations exist, so description carries burden; however, it omits side effects, persistence, or exactly which fields are conservative.

  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, front-loaded with purpose and key details. Every word adds value; no redundancy.

  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 high parameter count (17) and no schema descriptions, the description explains only a fraction of parameters and omits output format or usage examples. Output schema exists but not referenced, so completeness is low.

  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?

  With 0% schema coverage, the description highlights key parameters (api_key, base_url, model, timeout) and hints at boolean parameters ('send_*') via 'conservative fields'. Does not explain many other parameters (e.g., aspect_ratio, quality), leaving gaps.

  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?

  Identifies as a 'temporary exploration tool' for OpenAI Images, clearly distinguishing it from the 'official' sibling. The verb 'explore' is somewhat vague but adequate given the name.

  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?

  Describes per-call customization (api_key, base_url, model, timeout) and default conservative sending, implying use for testing/config exploration. No explicit when-not or alternatives to siblings, but context is sufficient.

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

• gpt_image_2_officialA
  3.6/5.0
  Behavior3/5

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

  No annotations exist, so description bears full burden. Explains preset/API key behavior and that it generates/edits images, but lacks details on rate limits, error handling, or file overwrite behavior. Adequate but not comprehensive.

  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 about 5 sentences, front-loads main purpose, and is efficiently structured. Could be slightly more concise but imparts necessary context without excess.

  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 core functionality and important preset/API key interactions, and references prerequisite catalog call. However, with 16 parameters, many (e.g., mode, images, mask) lack sufficient explanation. Output schema exists but description could better connect mode to generate/edit behavior.

  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%, but description adds meaning for image_size and aspect_ratio by mentioning they derive provider size preset. However, other parameters like quality, output_format, images, mask are not explained in description beyond schema enums.

  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 the tool generates or edits images via the OpenAI Images compatible gateway. However, it does not explicitly differentiate from sibling tools like gpt_image_2_temporary, which may have similar purpose but different scope.

  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 preset/API key overrides and when to call list_image_tools_catalog first. However, it does not specify when to use this tool versus gpt_image_2_temporary or other image tools.

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