Server Quality Checklist

Tool Scores

• edit_imageB
  3.4/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. While it mentions the tool edits images with a prompt and optional references, it doesn't disclose critical behavioral traits like whether this is a destructive operation (overwrites the original file?), what permissions are needed, rate limits, output format, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 extremely concise and well-structured: two sentences that efficiently convey purpose and usage guidelines. Every word earns its place with no redundancy or fluff. It's front-loaded with the core functionality followed by the key usage condition.

  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 mutation tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It adequately covers purpose and basic usage but lacks crucial behavioral context (destructive nature, permissions, output format) and doesn't compensate for the absence of structured metadata. The agent would be left guessing about important operational aspects.

  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 three parameters thoroughly. The description adds minimal value beyond what's in the schema: it mentions 'text prompt' and 'reference images' but doesn't provide additional semantic context like examples, constraints beyond the schema's max length, or how reference images are used. Baseline 3 is appropriate when the schema does the heavy lifting.

  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's purpose: 'Edit an existing image file with a text prompt, optionally using additional reference images.' It specifies the verb ('edit'), resource ('existing image file'), and key mechanisms (text prompt, reference images). However, it doesn't explicitly distinguish this from sibling tools like 'continue_editing' or 'generate_image' beyond mentioning file path requirements.

  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 guidance: 'Use this when you have the exact file path of an image to modify.' This gives a specific when-to-use condition. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, though the context implies 'generate_image' might be for creating new images rather than editing existing ones.

  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 mentions the tool uses Gemini and creates new images, but lacks details on behavioral traits like rate limits, authentication needs, output format, or potential errors. The description doesn't contradict annotations (none exist), but it's insufficient for a mutation tool with no annotation coverage.

  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 with zero waste: the first states the purpose and method, the second provides crucial usage guidance. It's front-loaded with the core function and efficiently distinguishes from siblings without unnecessary elaboration.

  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 mutation tool (image generation) with no annotations and no output schema, the description is incomplete. It covers purpose and usage well but lacks behavioral context like what the output looks like, error conditions, or limitations. The schema handles the parameter, but overall completeness is moderate given the tool's complexity.

  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 the single 'prompt' parameter with its type, description, and constraints. The description adds no additional parameter semantics beyond what's in the schema, such as prompt formatting tips or examples. Baseline 3 is appropriate when 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 states the specific action ('Generate a NEW image'), resource ('image'), and method ('from a text prompt using Gemini'). It explicitly distinguishes this tool from its siblings by specifying 'creating a completely new image, not when modifying an existing one,' which directly contrasts with 'continue_editing' and 'edit_image' tools.

  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 provides explicit guidance on when to use this tool ('ONLY when creating a completely new image') and when not to use it ('not when modifying an existing one'), with clear alternatives implied by the sibling tool names ('continue_editing' and 'edit_image'). This gives the agent precise context for tool selection.

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

• continue_editingA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it operates on session state ('LAST image... in this session'), is stateful ('Automatically uses the previous image'), and is designed for 'iterative improvements'. However, it doesn't mention potential limitations like session duration, error handling, or what happens if no previous image exists, leaving some gaps.

  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 front-loaded with the core purpose in the first sentence, followed by operational details and usage context. Every sentence earns its place: the first defines the tool, the second explains automation, and the third provides guidance. It's concise with zero 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?

  Given the tool's moderate complexity (stateful operation, 2 parameters), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, and key behavior. However, it lacks details on output format or error cases, which could be helpful for an agent. Since there's no output schema, some additional context on returns would improve completeness.

  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 both parameters thoroughly. The description adds no specific parameter semantics beyond implying 'prompt' is for 'changes to make' and 'referenceImages' might be optional references. This meets the baseline of 3 since 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 states the specific action ('Continue editing'), the resource ('the LAST image generated or edited in this session'), and distinguishes it from siblings by emphasizing it works on the 'previous image without needing a file path' unlike edit_image which likely requires a file path. The phrase 'iterative improvements' further clarifies its unique role.

  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 states when to use this tool ('Continue editing the LAST image... in this session') and provides clear alternatives by naming sibling tools (edit_image, generate_image) in the context. It specifies 'Automatically uses the previous image' which implies when not to use it (e.g., when starting fresh or editing a different image).

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