Server Quality Checklist

Tool Scores

• check_provider_healthA
  4.5/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 of behavioral disclosure. It explicitly states the tool avoids loading kokoro/faster-whisper models, which is a key behavioral trait that prevents surprise time/disk costs. It also indicates that the check covers both network reachability and dependency installation, adding useful detail beyond a simple status check.

  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, well-structured sentence that front-loads the core purpose ('Check whether...') and then adds a parenthetical rationale for avoiding heavy model loads. Every clause earns its place; there is no filler or repetition.

  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 zero-parameter health check with an output schema, the description covers all necessary context: what is checked, why it avoids model loading, and what aspect of fallback dependencies it verifies. It does not need to explain return values because the output schema exists.

  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 need not explain parameter meaning because there are none. It focuses instead on the tool's purpose and behavior, which is appropriate here.

  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 names a specific verb ('check') and resource ('Groq's hosted TTS/STT endpoints' and 'local fallback's optional dependency'), and clearly distinguishes itself from the sibling tools by focusing on health/readiness rather than performing TTS/STT operations. It leaves no ambiguity about what the tool does.

  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 conveys a clear context: this is a quick health check meant to verify reachability and dependency installation before heavier operations. It does not explicitly name sibling alternatives or state 'use before text_to_speech', but the purpose and the warning against model loading imply when it should be used. The absence of explicit exclusions keeps it at a 4 rather than a 5.

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

• speech_to_textA
  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 transparency burden. It discloses the Groq-first fallback, the GROQ_API_KEY requirement, the optional local-stt extra, first-use model weight download, and that the local fallback ignores language hints. It does not mention error handling or network assumptions, but the core operational behavior is well covered.

  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 appropriately concise and front-loaded with the main purpose, followed by a compact Args block. Every sentence adds useful operational or parameter detail; there is no 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 has a fallback architecture and conditional setup requirements, and the description covers all of these: provider order, fallback trigger, setup extra, model weight download, and input constraints. Since an output schema exists, the absence of an explicit return-value description is acceptable, and an agent has enough information to invoke the tool correctly.

  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 for parameters, so the description must compensate. It fully explains audio_path as an absolute path with supported formats and max size, and language as an optional ISO-639-1 hint with example and fallback-specific behavior.

  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 states a specific action and resource: 'Transcribe a local audio file to text.' This is unambiguous and clearly different from sibling tools like text_to_speech, list_voices, and check_provider_health.

  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 usage context: it is for local audio files, lists supported formats and the 25MB limit, and explains the optional language hint. It does not explicitly name sibling alternatives or state 'when not to use,' but the transcription versus speech-synthesis distinction is obvious from the sibling names.

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

• list_voicesA
  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 behavioral disclosure. It explicitly warns that the list is static, transcribed from public docs, not fetched live, and can drift. It also clarifies the scope of the health check sibling, which is valuable beyond the function's obvious purpose.

  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 and front-loaded with the tool's purpose, followed by essential caveats about staleness and health checking. Every clause adds value; there is no filler or redundant restatement of the tool name.

  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 zero-parameter tool with an output schema, the description covers the essential context: what the tool lists, where the data comes from, its limitation, and how to verify current functionality via a sibling tool. Nothing important is missing.

  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 schema already fully covers parameter semantics. The description adds useful context about what the returned voice names are and how they relate to text_to_speech, which meets the baseline for a no-parameter tool.

  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 states a specific verb and resource: it lists known Groq PlayAI voice names for use with text_to_speech's voice argument. It clearly distinguishes this from sibling tools by tying the list directly to another tool's parameter.

  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 that this is a static list and advises that check_provider_health only verifies the default voice, not the full list. This implies when to use this tool and when to use the health-check sibling, though it does not explicitly state exclusions for speech_to_text.

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

• text_to_speechA
  4.8/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 does so thoroughly: it discloses provider fallback order, that the local fallback always emits .wav regardless of output_format, that voice is ignored on the local tier, and exact prerequisite setup (local-tts extra and espeak-ng).

  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 content is front-loaded with the one-line summary, followed by dense but relevant provider/fallback details and an Args section. Every sentence adds operational value with no 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?

  For a tool with no annotations and no parameter descriptions, the description covers provider selection, key requirements, output-directory behavior, and per-parameter semantics. An agent has enough information to invoke it correctly without inspecting sibling tools or external docs.

  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 manually documents all three parameters: text, voice (with example and fallback behavior), and output_format (with allowed values and the caveat that it is only honored on Groq). This fully compensates for the empty 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 specific verb and resource: 'Convert text to speech, saved to output/.' This makes the tool's function immediately clear and distinguishes it from siblings such as speech_to_text (reverse direction) and list_voices/check_provider_health (support tools).

  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 clearly states the primary purpose and the conditions under which each provider path is used: Groq first when available and the key is set, local fallback otherwise. It doesn't explicitly name when-not-to-use cases, but no sibling tool competes for this task, so clearer context would be marginal.

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