Server Quality Checklist

Tool Scores

• tools_healthA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific behavior of checking all model APIs and returning readiness, but does not go beyond that to mention potential side effects, requirements, or response details.

  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 succinct sentence that fully conveys the tool's purpose and return value. No 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?

  For a simple health check tool with no output schema, the description is sufficient. It states what it does and what it returns. Slight room to mention interpretation of results (e.g., what 'ready' means) but not necessary given the annotations.

  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 no parameters, so there is nothing for the description to explain. The baseline for zero parameters is 4, and the description does not need to add parameter-level detail.

  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 availability status of all model APIs and returns readiness. The verb 'check' plus resource 'all model APIs' is specific and distinguishes it from siblings like vision_analyze, vision_chat, and audio_transcribe.

  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?

  Usage context is implied: this is a health check tool, so it would be used to verify model availability before other operations. However, the description does not explicitly state when to use it or provide exclusions or alternative guidance.

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

• vision_analyzeA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that it accepts URL or base64 images and returns structured JSON with summary, text, and object list, which is useful behavioral context beyond 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 compact at three short sentences. Each sentence provides distinct information: what it does, input support, output format, and when to use it, with no 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?

  The description covers the tool's core inputs and outputs, and annotations supply safety context. While no output schema exists, the return format is summarized. It lacks some edge-case details but is sufficient for a simple, low-risk tool.

  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 covers all four parameters with 100% description coverage. The tool description repeats that URL and base64 are supported (image_url/image_data) but adds no extra semantic detail beyond what the schema provides, so the baseline of 3 applies.

  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: analyzing image content. It specifies the resource (images) and action (analyze), and distinguishes itself from sibling tools like vision_chat and audio_transcribe by noting its structured JSON output and one-time analysis nature.

  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 notes that it is suitable for one-time image analysis, giving clear usage context. It does not explicitly exclude multi-turn conversations or name alternative tools, but the one-time framing implies a boundary against vision_chat.

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

• vision_chatA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnly/openWorld/idempotent hints. The description adds that replies are automatically concise and supports multi-turn with images, giving useful behavioral context beyond 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?

  Two concise sentences: first states the core purpose, second differentiates from the sibling. No 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?

  For a simple single-parameter tool with strong annotations and schema, the description covers purpose, distinguishes from sibling, and notes reply style. It could mention response format, but absence of an output schema makes this acceptable.

  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 only parameter 'messages' is fully documented in the schema (100% coverage). The description does not add further parameter-level detail, 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?

  Description clearly states it is a multimodal conversation tool supporting multi-turn chat with images. It explicitly distinguishes from the sibling vision_analyze by directing users to that tool for structured JSON 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?

  Provides explicit guidance by naming vision_analyze as the alternative for structured analysis, implying vision_chat is for conversational use. The context is clear, though it does not list exhaustive when-not-to-use scenarios.

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

• audio_transcribeA
  4.4/5.0
  Behavior5/5

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

  Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable contextual details: it uses faster-whisper small model with CPU-only INT8 quantization, and it returns segmented text and full text. This gives the agent a richer understanding of performance and output characteristics beyond the 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, consisting of three focused sentences. It front-loads the core purpose, then adds model details, supported formats, and output type, with no unnecessary words. Every sentence adds meaningful info.

  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?

  Moderate complexity tool with no output schema, but the description explains what is returned (segmented text and full text). It covers supported formats and the CPU-only constraint. It doesn't mention error handling, file size limits, or prerequisites, but for a read-only transcription tool, these are less critical. Overall, it's sufficiently complete 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.

  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 (file_path, task, language). The description does not add additional parameter semantics—it only mentions supported formats and output, which are not directly tied to parameter usage. Thus, baseline score 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's function: '本地音频转写' (local audio transcription) using a specific model. It distinguishes from sibling tools (vision_analyze, vision_chat, tools_health) by focusing on audio-to-text conversion, making its 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 context that this is for transcribing local audio files, listing supported formats and model constraints. It doesn't explicitly mention alternatives or when-not-to-use, but the sibling tools are visually/health-oriented, so the usage context is clear enough without exclusions.

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