Server Quality Checklist

Tool Scores

• clear_conversationB
  3.4/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 indicates a destructive action ('clear') but does not state whether the operation is irreversible, affects persistent storage, requires specific permissions, or what the outcome will be. 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 a single, front-loaded sentence that states the action and object directly. Every word adds value, with no redundancy or filler.

  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?

  For a simple tool with one parameter and no output schema, the description still omits critical behavioral context such as permanence of deletion, side effects on active chat sessions, or whether any confirmation is required. The lack of annotations and output schema places the burden on the description, which does not meet it.

  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%, as the only parameter (conversation_id) is described as 'The conversation ID to clear'. The tool description adds no additional semantic detail beyond referencing 'a specific conversation ID', which matches the schema. Thus the baseline score of 3 is appropriate.

  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 action ('Clear') and the resource ('conversation history') with a specific scope ('for a specific conversation ID'). It is unambiguous and distinguishes itself from sibling tools, which handle image generation, chat, and model settings.

  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 (call this when you need to clear a conversation's history) but provides no explicit guidance on when to use it versus alternatives or any exclusions. Since no sibling performs a similar function, explicit alternative guidance is not necessary, but the description still lacks any context about prerequisites or suitability.

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

• gemini_edit_imageB
  3.4/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 of disclosing behavioral traits. It mentions session history references and 'image consistency features,' but doesn't explain what the tool returns, whether the original image is modified or a new file is created, or any side effects like default save location (which appears only in the schema). This is insufficient for a tool that modifies 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?

  The description is just two sentences, front-loaded with the core purpose and followed by a useful capability note. There is no wasted wording, and it avoids repeating schema details. It's concise and directly readable, though the phrase 'image consistency features' is slightly vague but not excessive.

  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 (7 parameters) and absence of an output schema, the description should explain return values and behavioral outcomes, but it doesn't. It also leaves 'image consistency features' undefined, forcing the agent to infer from the schema. Missing information about default output behavior and effects on the original image makes the description incomplete for safe autonomous use.

  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 parameter meanings are already documented. The description's mention of history references and consistency adds no new information beyond the schema's detailed parameter descriptions. Baseline 3 is appropriate because the schema does the heavy lifting.

  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 identifies the tool's purpose: 'Edit or modify existing images based on prompts.' The verb 'edit/modify' plus the resource 'existing images' distinguishes it from sibling gemini_generate_image, which creates new images. It also mentions key capabilities like history references, making the purpose unambiguous.

  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—edit existing images when you have a prompt—but provides no explicit guidance on when to use this tool versus alternatives like gemini_generate_image or gemini_chat. It doesn't state exclusions or name alternative tools for different scenarios, so guidance is only implied, not explicit.

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

• gemini_generate_imageB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of disclosing side effects and behaviors. It fails to mention that the tool saves images to disk (defaulting to ~/Documents/nanobanana_generated/), any network/API usage, authentication requirements, or return values. It only mentions session-based consistency, which is a feature but not a behavioral disclosure.

  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 that front-load the core purpose. Every word adds value, and there is no redundancy or filler.

  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 a 7-parameter schema and no output schema, the description does not explain the tool's overall behavior (e.g., where the generated image goes, what the tool returns, or how the session mechanism operates). The session consistency mention is a start, but the description is too sparse for the complexity involved.

  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 all seven parameters are already documented in the schema. The description adds no new parameter-level semantics beyond what the schema provides, making the baseline 3 appropriate.

  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 images via Gemini, and mentions a key differentiator (session-based image consistency) that distinguishes it from siblings like gemini_chat or gemini_edit_image. The verb and resource are specific and unambiguous.

  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 the tool is for generating new images and optionally using session consistency, but it does not explicitly address when to use this tool versus alternatives like gemini_edit_image or gemini_chat. No exclusion criteria or alternative recommendations are given, so usage guidance is only implied.

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

• gemini_chatA
  3.6/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. It discloses multi-turn support and image limit, but omits return format, authentication/rate limits, and side effects. For an external API call, this is a partial disclosure; not misleading but 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?

  A single, front-loaded sentence that immediately identifies the action and resource. It adds two key capabilities without waste.

  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?

  No output schema, so the description should clarify what the tool returns (e.g., text response), but it does not. It also lacks practical guidance on using conversation_id for multi-turn beyond the schema, leaving gaps for a 4-parameter tool with no annotations.

  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 baseline 3. The description adds context like 'multi-turn' (relating to conversation_id) and 'reference images,' but these are largely redundant with the schema's own parameter 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 clearly states the tool's purpose: 'Chat with Gemini 3.1 Flash model.' It uses a specific verb and resource, and the mention of multi-turn and reference images distinguishes it from sibling image generation/editing and conversation management tools.

  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?

  Usage is implied: this is the chat tool. However, there is no explicit guidance on when to use it versus siblings like clear_conversation or set_model, nor prerequisites for multi-turn (e.g., conversation_id). The description implies but does not instruct.

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

• set_modelA
  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 must carry the behavioral disclosure burden. It states the action ('set') but omits any side effects, persistence, session scope semantics, or whether changing the model affects existing conversations. The word 'session' hints at scope but lacks explicit detail, leaving the agent to infer the behavioral contract.

  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. The first sentence immediately identifies the action and scope; the second adds necessary selection guidance. No words are wasted, and the structure is front-loaded.

  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?

  For a simple setter tool with full schema coverage, the description is mostly adequate. However, it lacks any mention of return value or confirmation, and without annotations it does not address persistence or side effects. Given the low complexity, this is a moderate gap; the description is complete enough to use but not fully self-contained.

  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 parameter semantics are already well-documented. The description adds value by clarifying the trade-off between 'flash' and 'pro' (speed vs. quality), which supplements the schema's enum descriptions. However, it does not mention the conversation_id parameter or its default, but since the schema covers that and the description's 'for this session' hints at it, a baseline score of 3 is appropriate.

  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 ('Set') and resource ('the Gemini model for this session'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like gemini_chat or gemini_generate_image by focusing on session-level configuration.

  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 choose each model value: 'flash' for faster generation and 'pro' for higher quality, which is directly actionable for the primary parameter. However, it does not explicitly mention alternatives like set_aspect_ratio or when not to use this tool, though that context is somewhat implied by the sibling set.

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

• get_image_historyA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool retrieves a list ('Get the list'), which suggests a read-only operation, but it does not explicitly confirm it has no side effects, or describe output details or limitations. The behavior is basic but adequately conveyed.

  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 with no filler. It communicates the essential purpose in eleven words.

  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?

  For a simple tool with one parameter and no output schema, the description provides enough information: it tells the user what the tool returns (a list of images) and the scope (session). No significant gaps are present.

  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 already fully describes the only parameter (conversation_id), and the description does not add any new details about format or semantics beyond confirming it is session-based. With 100% schema coverage, the baseline of 3 is appropriate.

  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 'Get' and the resource 'list of generated/edited images in a session'. This clearly distinguishes it from sibling tools like gemini_generate_image or gemini_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 Guidelines3/5

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

  The phrase 'for reference' implies a use case of retrieving past images, but it does not explicitly state when to prefer this tool over others or mention alternatives/exclusions. The usage context is only implied.

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

• set_aspect_ratioA
  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 full burden. It discloses the session-scoped effect and the ordering requirement, but does not clarify behavior like overriding previous settings, persistence across sessions, or the relationship between 'session' and the conversation_id parameter.

  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, front-loaded with the verb and key resource, followed immediately by the usage rule. 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?

  For a simple setter tool with a fully described schema, the description covers core purpose and usage timing. Minor ambiguity exists around 'session' vs conversation_id and default ratio behavior, but overall it is sufficiently complete for the tool's simplicity.

  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%: both parameters have descriptions, and aspect_ratio has a detailed enum. The description adds no additional parameter semantics, so baseline 3 is appropriate.

  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: 'Set the aspect ratio for subsequent image generation and editing in this session.' It uses a specific verb and resource, and distinguishes itself from sibling tools like set_model and the actual image generation/editing 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?

  Explicit guidance is given: 'Must be called before generating/editing images if a specific ratio is desired.' This states when to use the tool and the condition under which it applies, though it does not mention alternatives or explicit exclusions.

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