Server Quality Checklist

Tool Scores

• get_tagB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It states the action (analyze tags and retrieve text) but does not mention read-only semantics, error behavior, preconditions (e.g., image must exist), or any side effects. This leaves significant behavioral ambiguity.

  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 redundant words or filler. It efficiently conveys the core functionality without unnecessary detail.

  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?

  Although the tool is simple and has an output schema, the description lacks essential context for agent selection: no usage guidelines, no behavioral traits, and no differentiation from sibling tools. It is minimally adequate for understanding purpose but incomplete for confident invocation in a broader toolset.

  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 0%, so the description compensates by indicating that both 'subfolder' and 'filename' are used to specify the image. However, it does not elaborate on formats, path conventions, or the relationship between the two beyond the obvious, leaving some semantic gaps.

  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: given a subfolder and filename, it analyzes the corresponding generated image and retrieves WD1.4 tags as text. It uses a specific verb (取得する/retrieve) and resource (WD1.4 tags), and it is distinct from siblings like get_caption and get_picture.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like get_caption or get_picture. The usage context is only implied by the purpose, with no explicit exclusions or alternative recommendations.

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

• get_captionA
  3.7/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 clearly indicates this is a read operation ('取得する' = retrieve) and specifies the output format ('テキスト形式' = text format), which goes beyond what the tool name reveals. It does not mention error behavior or permissions, but the simple getter nature is transparent enough.

  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, compact sentence that front-loads the action and resource. Every word is necessary, with no filler or repetition.

  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, has an output schema (so return values are covered), and the description sufficiently explains what the tool does. The main gap is the lack of usage guidance, but for a straightforward getter, the description is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, and the description merely restates the parameter names ('subfolder と filename を指定して') without providing additional meaning, format, or constraints. It vaguely indicates they identify which image's caption to retrieve, but does not clarify what values are valid or what subfolder refers to.

  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 a specific action (retrieve/get), a specific resource (caption of a generated image), and the required parameters (subfolder and filename). It effectively distinguishes from siblings like get_picture and get_tag by specifying that it retrieves the caption in text format.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No explicit guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it relates to get_picture or get_tag. The usage context is only implied by the tool name and siblings.

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

• get_pictureA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It states the output is a PNG binary, but does not mention error handling, permissions, path resolution, or any side effects. The tool is likely a read operation, but this is not stated. Minimal behavioral disclosure beyond the basic action.

  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 sentence that directly conveys the purpose and required inputs. There is no redundancy or extraneous information. It is appropriately sized for the tool's simplicity.

  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 adequately covers the core function and input for a simple retrieval tool, but with no annotations or output schema, it lacks details on response format (e.g., binary vs base64), error conditions, or constraints. It is minimally complete but leaves some ambiguity.

  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 provides no descriptions for the two string parameters, and the description only says they are used to specify the location. It does not clarify what the subfolder is relative to, or any expected format. This adds minimal value beyond the parameter names themselves.

  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: to retrieve a PNG binary by specifying a subfolder and filename. This distinguishes it from sibling tools like generate_picture (which creates) and the caption/tag tools (which analyze metadata). The verb '取得する' (retrieve) is 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 Guidelines4/5

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

  The description implies the tool is for retrieving existing images, which distinguishes it from generate_picture. However, it does not explicitly mention alternative tools or provide exclusionary guidance. The context is clear but lacks explicit 'when/not' instruction.

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

• generate_pictureA
  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 full burden. It discloses the language constraint (English only) and that the output is a URL to present to the user, which are key behavioral traits. It does not cover potential content restrictions or generation latency, but for a simple generation tool this is adequate.

  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: the first states the core functionality and output, the second adds the language constraint. No wasted words and the most important information is front-loaded.

  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 single-parameter tool with an output schema, the description covers the essential aspects: what it does, what input it needs, the language requirement, and what to do with the result. It is complete for the tool's complexity.

  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%, so the description must fully explain the 'prompt' parameter. It does so by specifying that the prompt is the content to generate and that it must be in English (with translation guidance), adding meaning beyond the bare 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 generates an image from a supplied prompt and returns the image URL. This distinctly differentiates it from sibling tools like get_picture (retrieval) and get_caption/get_tag (analysis).

  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 context for when to use the tool (generation requests) and gives explicit guidance on translating non-English prompts to English. However, it does not explicitly mention when not to use it or name alternative tools for retrieval, so it falls short of full differentiation.

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