Server Quality Checklist

Tool Scores

• get_aspect_ratiosA
  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 of behavioral disclosure. It states that the tool returns a list and describes the grouping behavior when mode is omitted. This gives a clear picture of the read-only nature. It does not mention potential quirks like sorting, errors, or authentication, but for a simple listing tool the description is reasonably transparent.

  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 purpose, and contains no unnecessary wording. Every piece of information earns its place.

  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 low complexity (one optional enum parameter, no output schema, no annotations), the description is largely complete. It explains the main behavior and the two modes of operation. However, without an output schema, it could be more explicit about the exact return structure beyond just 'list grouped by model.'

  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 covers 100% of parameters, with the 'mode' parameter fully described as 'Model mode.' The description adds the behavior when omitted (grouped by model) but this is more about tool behavior than parameter semantics. It does not add significant new meaning beyond the schema, so 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 clearly states the tool returns a list of available aspect ratios for image generation. It uses a specific verb ('Returns') with a clear resource ('aspect ratios') and provides context ('for image generation'). This distinguishes it from siblings like get_models 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 clear parameter usage instructions: 'Pass a mode to get ratios for a specific model, or omit to see all ratios grouped by model.' However, it does not explicitly discuss when to use this tool versus alternatives such as get_models or when not to use it. The usage guidance is implied rather than explicitly contrasted with siblings.

  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
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses async behavior ('submits a job then polls'), status lifecycle, recovery instructions, and API key requirement. However, it does not mention rate limits, costs, or the exact return format, which are notable omissions 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 three sentences, front-loaded with the core purpose, followed by async flow and recovery. Every sentence adds essential behavioral or operational information with no fluff.

  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?

  While the description covers the async flow and error recovery, it lacks explanation of the return value (there is no output schema) and doesn't mention in the description itself that one should verify supported aspect ratios or craft prompts (though these are in schema). Given the tool's complexity and absence of output schema, this gap leaves the agent uncertain about what the 'result' contains.

  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 baseline is 3. The description itself adds no parameter-specific details, but the schema already provides rich descriptions for mode, ratio, and prompt, including supported ratios per model and a reference to create_prompt, thus fully compensating for the description's silence.

  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 'Generates an image using the Budka (CyberPhotoBooth) API', specifying the action and resource. It distinguishes from siblings like check_job (for retrieving results) and get_models (for listing models), 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 Guidelines4/5

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

  The description provides clear guidance on when to use this tool vs check_job in case of timeout/interruption ('If timed out or interrupted, use check_job... without creating a new job'). It doesn't explicitly mention using get_aspect_ratios or create_prompt, but those are suggested in the schema's parameter descriptions, offering context beyond the main description.

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

• create_promptA
  4.2/5.0
  Behavior4/5

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

  The description reveals behavior beyond the schema: it optimizes the input into an English prompt, follows 'best practices,' and removes gender/count specifics ('universal'). Since no annotations are provided, this is helpful. It doesn't contradict any annotations.

  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 concise, with three short sentences that are front-loaded with the main action. Each sentence contributes distinct value: function, usage suggestion, and output trait. No redundant wording.

  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 simplicity (2 params, no output schema), the description covers the core behavior and output. It specifies the model (Flux Klein) and the result (optimized prompt). It could explicitly mention returning the prompt text and note its role as a precursor to generate_image, but these are minor 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 input schema already includes descriptions for both parameters, including the length enum with word ranges and the description parameter with theme/style/mood/setting examples. The tool description adds little new parameter information—it repeats 'theme, style, mood' but omits 'setting' and 'any language'. Thus, 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 primary action: 'Generates an optimized English prompt for Flux Klein image generation model based on your description.' This specifies the verb, resource, and target model, differentiating it from sibling tools like 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 Guidelines4/5

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

  The description indicates when to use it: when you have a description and want a well-structured prompt. However, it does not explicitly mention alternatives or when not to use it (e.g., if you already have a prompt, use generate_image directly). The context that it is for the Flux Klein model provides guidance.

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

• get_modelsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description must convey behavior. The verb 'Returns' indicates a read-only operation without side effects, which is useful. However, it doesn't disclose additional behavioral traits such as whether the list is exhaustive, cached, or requires any setup. Given the simplicity, this is adequate 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?

  Two sentences, first states purpose, second gives usage. No redundant information.

  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 parameterless read tool, the description fully covers what it does and when to use it. No output schema exists, but the return value is described as the list of models, fulfilling the need.

  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, so schema coverage is trivially 100%. The description doesn't need to explain parameters, and as per baseline for 0 params, a score of 4 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 'Returns the list of available image generation models' with a specific verb and resource. It distinguishes from sibling tools by focusing on 'models,' which is distinct from aspect ratios, prompts, jobs, and 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 Guidelines4/5

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

  Provides explicit guidance 'Use this when user asks which models are available.' This is a clear condition for use. It doesn't mention alternative tools or when not to use, but the context is sufficient for a simple listing tool.

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

• check_jobA
  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 implies a read-only operation by saying 'without creating a new job' and indicates it retrieves results. It could disclose more about return values or error behavior, but it does convey the main non-mutating trait.

  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: the first states the function, the second gives usage context. Every word is useful, no redundancy, and it is front-loaded with the core purpose.

  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?

  The tool is simple with one param and clear schema. The description explains its purpose and when to use it, which is sufficient for basic operation. However, without an output schema, explicitly stating the return format (e.g., status versus image URL) would improve completeness, but the description does say 'retrieve the result', which implies returning the output.

  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 provides 100% coverage for the single param job_id, describing it as returned by generate_image. The description adds no extra param details, but with complete 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 clearly states the tool checks the status of a previously submitted image generation job, using specific verbs and a resource. It distinguishes itself from siblings like generate_image by explicitly mentioning it retrieves results without creating a new job.

  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?

  It gives explicit when-to-use guidance: use it if generate_image timed out or was interrupted. This provides a clear alternative context and directly tells the agent when this tool is appropriate compared to generating a new job.

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