Server Quality Checklist

Tool Scores

• make_maskA
  4/5.0
  Behavior3/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 the ratio-based coordinate system (0-1) and gives examples, which is valuable. However, it does not mention potential side effects like file overwriting or the exact mask format characteristics beyond 'PNG'.

  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, front-loading the purpose, then adding coordinate semantics and examples. It is concise and every sentence contributes useful information without redundancy.

  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 description covers the core behavior, coordinate system, and examples, which is largely sufficient for invoking the tool correctly. Gaps exist regarding expected mask appearance (e.g., fill color) but given no output schema and no annotations, the description does enough to guide an agent.

  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 schema only describes like_path and out_path, leaving the four coordinate parameters undocumented. The description compensates by explaining the ratio coordinate system and providing specific example values for left/top/right/bottom, adding essential 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's function: creating a mask PNG that specifies an elliptical editing region (e.g., mouth, eyes). It provides concrete coordinate examples, making the purpose unambiguous and distinguishing it from sibling tools like generate_image or compose_region.

  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 for facial region editing through examples, but does not explicitly state when to use this tool versus alternatives or mention any exclusions. The context is clear but lacks explicit guidelines about alternatives or when not to use it.

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

• generate_imageA
  4.2/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 and does disclose a key behavior: returns path rather than base64, and explicitly saves to file. It does not discuss permissions, error cases, or rate limits, which would be expected for a generation tool without 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 only two sentences: the first states core behavior concisely, the second offers domain-specific advice. No redundant content, and key facts are front-loaded.

  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 description, combined with a high-coverage schema and no output schema, appropriately covers behavior and a key use case. It doesn't describe errors or environmental dependencies, but for a generation tool this is sufficient.

  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?

  Although schema coverage is 100%, the description adds meaningful guidance for the prompt parameter, recommending solid background, no shadows/gradients, and face-forward for avatar use. This enriches the schema's minimal parameter description.

  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 prompt, saves it to a file, and returns the path, explicitly noting it does not return base64. This distinguishes it from sibling tools like edit_image and make_mask by emphasizing creation and file output.

  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?

  It provides a specific use case for avatar base generation with prompt styling tips, which gives context on when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full 5.

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

• compose_regionA
  4.4/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 and discloses notable behaviors: base is preserved bit-wise ('土台はビット単位で保たれる'), blur is applied only inside the mask ('境界のぼかしは内側にだけ入る'), and it auto-verifies base contamination if numpy is available ('numpy があれば土台の汚れを自動検証する'). It does not detail failure modes, but the disclosed behaviors go well beyond the name.

  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?

  Four sentences, no wasted words. The first sentence states the core function, followed by use-case, a caveat about blur, and a note about validation. Every sentence 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 no annotations and no output schema, the description covers the main aspects: purpose, use case, key behaviors, and edge-case handling (blur direction). It does not mention return values or error behavior, but for a compositing utility the provided context is sufficient for an agent to select and invoke it.

  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?

  Schema coverage is 100%, so each parameter already has a description. The description adds relationships between parameters (e.g., src_path is 'edit_image の出力', base_path is the fixed face) and explains the feather behavior (blur only inside), which enhances the meaning of the feather parameter. It scores above baseline 3 due to this cross-referencing.

  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 verb+resource: 'edit_image の結果からマスク領域だけを切り出し、土台画像へ合成する' (cut out only the masked area from edit_image result and composite onto base). It distinguishes from siblings by explaining the compositing role and even gives a concrete use case: 'アバターの差分絵を作るなら必ずこれを通す' (if making avatar diff images, be sure to use this).

  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 explicitly tells when to use the tool ('アバターの差分絵を作るなら必ずこれを通す'), and implies that it is the step after edit_image. It does not explicitly list alternatives or when-not-to-use, but the context is clear enough that it is the compositing step among the sibling tools.

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

• edit_imageA
  4.9/5.0
  Behavior5/5

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

  Annotations are absent, so the description carries full burden. It discloses critical measured behavior: passing a mask still regenerates the entire image, drift in non-mask pixels, and max difference. This goes far beyond the schema and is highly valuable for an agent.

  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 purposeful sentences. The first states purpose and mask behavior; the second provides concrete measured data and actionable advice without padding. Every sentence earns its place.

  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 6-parameter tool with no annotations and no output schema, the description covers the core purpose, the critical behavioral caveat, and recommends an alternative workflow. It is sufficiently complete for an agent to invoke the tool correctly.

  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?

  Schema coverage is 67%, and mask_path is already described in the schema. The description adds a crucial semantic correction: despite the mask, the whole image is regenerated. This meaningfully alters how the agent should interpret mask_path, but other parameters like size/model are not further clarified.

  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 '既存画像を編集する' (edits an existing image), using a specific verb and resource. It also mentions mask_path behavior, which distinguishes it from sibling tools like generate_image (new image generation) and compose_region (compositing).

  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 implies use for editing existing images and explicitly warns against using the result directly for character diff frames (30fps switching causes face wobble), instead recommending compose_region. This provides clear when-to-use and when-not-to-use guidance with an alternative tool.

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

• list_image_modelsA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and delivers: it discloses that the operation is not billed ('課金されない') and that it can be used for key validation, adding meaningful behavioral context beyond the basic function.

  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, front-loaded with the core purpose and immediately followed by an important usage note. Every word serves a purpose, no redundancy.

  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 simplicity (no params, no output schema), the description is complete. It clarifies the return intent (list of models), the cost behavior, and a critical usage reminder, fully equipping the agent for correct invocation.

  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 the baseline is 4. The description does not need to add parameter details, and it doesn't; it focuses on usage context, 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 enumerates image generation models available for the API key, using the specific verb '列挙する' (enumerate) and resource '画像生成モデル'. It distinguishes itself from sibling tools by focusing on listing and validating key access.

  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 instructs when to use this tool: to check if the API key is active and to always verify model names with this tool rather than guessing, especially for borrowed keys with potential restrictions. This is clear, actionable guidance.

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