Server Quality Checklist

Tool Scores

• configure_gemini_tokenA
  3.5/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. It merely says 'Configure your Gemini API token' without disclosing whether the token is stored persistently, overwrites existing configurations, or has any side effects. This is a significant gap for a mutation-like tool.

  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, clear sentence with no unnecessary words. It is appropriately front-loaded with the verb and object.

  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 tool is simple (1 param, no output schema), and the description states its purpose and domain. However, it lacks behavioral context such as persistence or success/failure indications, which matters given the absence of annotations. It is adequate but has clear gaps.

  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 schema already provides a description for apiKey ('Your Gemini API key from Google AI Studio'), and the description adds only the term 'token', which is synonymous. With 100% schema coverage, there is no additional meaning added.

  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 the specific verb 'configure' and identifies the resource 'Gemini API token', clearly distinguishing this from sibling tools like generate_image or get_configuration_status. It also connects to the domain of nano-banana 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for nano-banana image generation' implies this is a prerequisite for generation, but it does not explicitly state when to use it versus alternatives like get_configuration_status, nor does it mention exclusions. The usage is implied rather than explicit.

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

• edit_imageA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does not clarify whether the original file is overwritten, what the output of the operation is (e.g., a new file path), or any required permissions. The only behavioral detail is 'optionally using additional reference images', which is minor. This is a significant gap for a mutation tool.

  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 two sentences long, front-loaded with the primary action, and contains no redundant information. 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?

  The tool has 4 parameters, no output schema, and no annotations. The description is minimal but not entirely inadequate. It gives a clear when-to-use context and references the main input, but it lacks information about outputs, error handling, or side effects, which are important for a tool that modifies existing files.

  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 some context to imagePath by emphasizing 'specific existing image file', but it largely repeats what the schema already states. It does not add meaningful syntax or format details 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's function: 'Edit a SPECIFIC existing image file'. This distinguishes it from sibling tools like generate_image, which creates new images, and continue_editing, which implies a different workflow. The mention of 'specific existing image file' and 'exact file path' makes the purpose definite.

  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 a clear usage condition: 'Use this when you have the exact file path of an image to modify.' This gives explicit when-to-use guidance. However, it does not mention when not to use it or name alternative tools directly, so it slightly falls short of the top score.

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

• get_configuration_statusA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It says 'Check if...' which implies a read-only operation, but it does not disclose whether this is a local check, whether it makes network calls, or what happens if the token is missing—leaving the agent uncertain about side effects and behavior.

  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?

  One short sentence of 8 words. It is appropriately minimal for a zero-argument status check, with no wasted 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 the tool's simplicity, the description states the core action, but it lacks details on the return value or the meaning of 'configured' (e.g., environment variable present vs. valid API key). Since there's no output schema, this information is missing.

  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?

  There are 0 parameters, and the schema already reflects that with 100% coverage. The description doesn't need to explain any parameters, so the baseline 4 applies.

  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 a specific verb ('Check'), names the resource ('Gemini API token'), and specifies the outcome ('is configured'). This clearly distinguishes it from siblings like configure_gemini_token (writes) and 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?

  The description gives no explicit guidance on when to use this tool versus alternatives. It's implied that it's a status check for token configuration, but there's no mention of prerequisites or context (e.g., 'use before generating images').

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

• continue_editingA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosure. It adds useful behavioral context: the tool automatically uses the previous image, is session-scoped, and optionally accepts reference images. However, it does not disclose what happens when no image exists, or that the edited image becomes the new 'last image' for subsequent iterative edits. These are important behavioral traits for a stateful tool.

  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 two sentences, front-loaded with the core purpose and immediately stating the key differentiator. Every sentence earns its place with no redundant or vague language.

  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 simple 3-parameter tool with full schema coverage, the description is mostly complete. It explains what the tool does, when to use it, and the key automatic behavior. However, it omits the stateful effect that the edited image becomes the new 'last image' for future calls, which is relevant for iterative use. Minor gap.

  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%, so the schema already documents all parameters. The description reinforces that referenceImages are optional and mentions 'without needing a file path,' but it does not add meaning beyond the schema. It does not explain prompt syntax or aspect ratio behavior beyond what is already in the properties.

  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's purpose: 'Continue editing the LAST image that was generated or edited in this session' and explicitly differentiates from siblings by noting it 'automatically uses the previous image without needing a file path.' This gives a specific verb, resource, and scope, and distinguishes it from edit_image.

  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 clear usage context: 'Use this for iterative improvements, modifications, or changes to the most recent image.' It implies when to use this tool vs. alternatives (when you want to edit the last image without a file path), but does not explicitly name alternatives or state when not to use it. This is clear but lacks explicit exclusion criteria.

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

• generate_imageA
  4.1/5.0
  Behavior3/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. It discloses the core behavior (generating a new image) and explicitly excludes modification, which is useful. However, it does not mention potential side effects, permissions, or what happens to previous images. For a simple generation tool this is acceptable but not rich.

  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 two short sentences, front-loaded with the main action. It is concise, clear, and avoids 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?

  The description covers the tool's purpose and usage clearly, but with no output schema and no annotations, it falls short on explaining what the tool returns or any secondary effects. For a simple two-parameter tool, the description is adequate but not exhaustive.

  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% for both parameters, with detailed descriptions of what 'prompt' and 'aspectRatio' mean. The tool description adds no parameter-specific information beyond the schema, so the baseline score of 3 applies.

  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's function: 'Generate a NEW image from text prompt.' It specifies the verb (generate), resource (image), and source (text prompt). The emphasis on 'NEW' and 'not when modifying an existing one' distinguishes it from sibling tools like edit_image.

  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 explicitly provides when to use the tool ('ONLY when creating a completely new image') and when not to use it ('not when modifying an existing one'). This gives clear usage boundaries, even though it doesn't name the alternative tool directly.

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

• get_last_image_infoA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description must convey behavioral context. It explains that the tool returns metadata about the last session image and ties it to the editing workflow, but it does not disclose edge cases (e.g., no image yet) or any potential side effects, leaving the behavioral profile somewhat incomplete.

  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 two concise sentences, with the primary purpose stated upfront and the usage guidance in the second sentence. No superfluous 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 simple, parameterless tool, the description gives a good overview of its purpose and output. It mentions the kind of information returned (file path, size) and the appropriate context (before continue_editing), though it stops short of specifying behavior when no image exists. Given the lack of an output schema, this is adequate but not exhaustive.

  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?

  The tool has zero parameters, and the schema is trivially complete (100% coverage). The description does not need to elaborate on parameters; it adds value by describing the output (file path, size, etc.), which satisfies the baseline for a parameterless tool.

  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 a specific verb ('Get') and resource ('information about the last generated/edited image'), clearly distinguishing this read-only info tool from the generation/editing siblings. It also specifies the scope ('in this session') and hints at the output content (file path, size).

  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 explicitly states when to use the tool: to check what image is currently available for continue_editing. It provides a clear use case but does not enumerate alternative tools or exclusion criteria, so it falls short of full 5.

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