Server Quality Checklist

Tool Scores

• list_modelsA
  4.3/5.0
  Behavior4/5

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

  Despite having no annotations, the description transparently discloses that the tool reads model availability and default selections. It doesn't mention potential errors or prerequisites (like needing to set an API key), but for a read-only list operation, the behavioral surface is small and the description covers the essential behavior without contradiction.

  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, focused sentence that leads with the action 'List' and immediately specifies the resource and additional details about default selections. No redundant words, and the structure places the core purpose first.

  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 parameterless tool with an output schema present, the description is fully sufficient. It states exactly what the tool returns: available models and default choices. The provided output schema likely explains the return structure, so no further exposition is needed. The sibling tools don't introduce ambiguity that would require more context.

  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?

  This tool has zero parameters, so the description doesn't need to explain parameter syntax or meaning. The input schema confirms this, and the guideline for 0 params sets baseline 4. The description adds nothing about parameters because none exist, which 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 lists models available on the API key and notes the server's default picks for generation and vision. It uses a specific verb 'List' and the resource 'models', distinguishing it from siblings that set API keys or generate/describe images.

  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 to discover available models and defaults. However, it gives no explicit guidance on when to use it versus alternatives, nor when not to use it. Given its simple listing nature, the context is reasonably clear, so this is barely adequate rather than poor.

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

• describe_imageA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses accepted input formats (local paths or public https URLs), the ability to handle multiple images, and gives advice on specificity. It does not mention limitations like file size or access restrictions, but the disclosed details are meaningful and go beyond a simple operation statement.

  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 and front-loaded: a clear one-sentence purpose, a 'Useful for' bullet list, then an Args section. Every sentence adds value, and the example question is practical rather than filler.

  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?

  The tool is simple (2 params, no nested objects) and the description covers purpose, use cases, and parameter semantics. An output schema exists, so not detailing return values is acceptable. The description fully equips an agent to decide when and how to invoke the tool.

  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?

  Schema description coverage is 0%, so the description must fully compensate. It does: 'images' is explained as local file paths or public https URLs, and 'question' is explained with guidance to be specific, including a concrete example. This adds substantial meaning beyond the raw 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 uses a specific verb+resource phrase: 'Look at one or more images and answer a question about them.' It clearly distinguishes from siblings (generate_image creates images; list_models and set_api_key are unrelated) and provides concrete example use cases like reading screenshots and comparing 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 gives clear context for when to use the tool: it provides vision to a text-only model and lists several useful scenarios (reading text, describing photos, checking generated images, comparing images, extracting chart data). It does not explicitly name alternatives or state when not to use it, but the context is sufficient given the sibling tools.

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

• generate_imageA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility and excels: it reveals how reference image count changes behavior, states a hard limit of 6 images returning HTTP 400, explains that style follows the reference when 1 ref is used, and discloses the default save_path behavior and that the path is always reported. This is highly transparent.

  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 information-dense and organized with clear sections, front-loaded with the core purpose before diving into details. It is somewhat long, but each sentence earns its place by conveying necessary behavioral nuance and parameter guidance. The structure follows a logical flow from purpose to reference-image rules to argument definitions.

  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 the tool's complexity, lack of schema descriptions, and absent annotations, this description is remarkably complete. It covers usage, edge cases (3+ refs), error conditions (HTTP 400), return behavior ('returns the image itself' and path reporting), and parameter semantics. It leaves few gaps for an agent to misinterpret.

  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?

  Schema coverage is 0%, but the description meticulously explains every parameter: prompt ('full art-style description'), reference_images ('local file paths or public https URLs' plus the critical rule), size with examples ('1024x1024' or '1K'), ratio with examples, and save_path ('where to write the png' and default). It fully compensates for the sparse 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: 'Generate an image from a text prompt.' It distinguishes itself from sibling tools like describe_image by specifying it generates rather than analyzes imagery, and the detailed behavior around reference images further clarifies its unique purpose.

  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 gives explicit guidance on when to use 0, 1, or 3+ reference images, and explains the tradeoff between style and likeness control, including a practical workaround for both. It does not explicitly mention sibling alternatives, but the content strongly implies when this tool is appropriate for image generation tasks.

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

• set_api_keyA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses side effects: key is verified before writing, stored in plain text at a specific path, sent only to Agnes, and the run_check will generate and read back an image. It also notes that typos fail early, providing clear behavioral expectations.

  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 somewhat long but every sentence adds value: security, verification, environment precedence, and verbatim reporting instruction. It is well-organized with an Args section, but could be tightened slightly by merging the 'whole install' sentence.

  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 this is a setup tool with two parameters and no annotations, the description covers all necessary context: what it does, when to call it, side effects, return handling, and parameter details. The presence of an output schema is not needed because the description tells the agent to relay the message verbatim.

  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?

  The schema provides no descriptions, and schema coverage is 0%. The description compensates fully by explaining the key format ('sk-'), the free source, and the time cost (20-60s) and purpose of run_check, going far beyond the raw 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 opens with a clear verb+resource: 'Set up this server with the user's API key.' It distinctively describes the installation scope and is clearly differentiated from sibling tools like generate_image and describe_image, which are runtime operations.

  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?

  Explicit usage instruction: 'Call this as soon as the user provides a key.' It also tells when to skip the run_check ('Only skip it if the user is in a hurry'), and clarifies precedence with 'AGNES_API_KEY in the environment still wins if set.'

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