Server Quality Checklist

Tool Scores

• create_and_translate_missing_languagesA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It discloses the core mutations (creating directories and translating strings.xml) but does not mention potential side effects, such as whether existing files are overwritten, whether network calls are made, or what the return value is.

  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 that contains all necessary information without extraneous detail. Every word earns its place.

  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?

  Given the simple tool shape (one optional parameter, no output schema) the description is adequate for basic invocation, but it omits explicit guidance on when to use this tool relative to sibling tools and does not mention return values. It is complete enough for a simple scenario but leaves some ambiguity when compared to translate_module.

  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 single parameter projectRoot is fully described in the schema as an optional Android project root directory. The tool description adds no parameter-specific information beyond the schema, 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 creates missing language directories and translates the default strings.xml into them, using specific verbs and resources. It distinguishes from siblings by focusing on missing languages and the default strings.xml source.

  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 missing languages through its name and phrasing, but does not explicitly state when to choose it over translate_all_modules or translate_module. No exclusions or alternative tools are mentioned, leaving the agent to infer the appropriate context.

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

• translate_all_modulesA
  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 reveals the use of git diff for detection but does not mention that translation likely modifies files, whether changes are committed, or the risk of unintended modifications. The description omits key side effects and prerequisites.

  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, concise sentence that front-loads the main action and includes the method (git diff) and scope (all supported languages). Every word contributes to understanding.

  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 is adequate for a relatively simple tool but lacks details on output, prerequisites (e.g., existing git repo, clean working tree), and side effects of translation. With no output schema and no annotations, more context would be needed for an agent to fully anticipate tool behavior.

  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 provides 100% coverage with a description for projectRoot, so the baseline is 3. The tool description adds no additional semantic details about the parameter beyond what the schema already states.

  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 action: detect changes in all default strings.xml files via git diff and translate them to all supported languages. It specifies a concrete resource (all default strings.xml files) and distinguishes from the sibling translate_module by covering all modules.

  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 usage context: for batch detection and translation across all modules. However, it does not explicitly mention alternatives like using translate_module for a single module or check_changes to only detect changes, nor does it state when not to use this tool.

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

• check_missing_languagesA
  3.8/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 of behavioral disclosure. It indicates a read-only 'check' operation but does not describe the output format, where TRANSLATION_LANGUAGES is configured, or how missing languages are reported. While the action is clearly non-destructive, significant behavioral details are unaddressed.

  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 core purpose. Every word contributes meaning, with no unnecessary elaboration 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?

  For a simple tool with one optional parameter and no output schema, the description provides the essential context: what operation is performed and what is compared. It does not explicitly relate to sibling tools, but the simplicity of the operation means the description is largely complete, save for minor details like the source of TRANSLATION_LANGUAGES.

  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 a description for the single optional parameter projectRoot, achieving 100% schema coverage. The tool description adds no additional parameter context, so the baseline of 3 applies; the schema sufficiently explains the parameter's meaning.

  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 specific function: checking which language directories are missing relative to TRANSLATION_LANGUAGES. The verb 'check' combined with the resource 'missing language directories' and the comparison against a configured list distinguishes it from the sibling tools, which focus on translating or checking changes.

  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 is implied by the tool's purpose—it is for identifying missing language directories—but there is no explicit guidance on when to use it versus alternatives like check_changes or create_and_translate_missing_languages. No exclusions or prerequisites are mentioned, so the agent must infer the appropriate context.

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

• check_changesA
  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 burden of disclosing behavior. 'Check' and 'without translating' clearly signal a non-mutating, read-only operation, which is useful. However, it does not mention what the tool outputs or any assumptions (e.g., git usage), so a perfect score is not warranted.

  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 with no filler. It front-loads the action and resource and includes a useful qualifier, making every word earn 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?

  For a simple tool with one optional parameter and no nested schemas, the description provides adequate context. It conveys the tool's scope and non-translating behavior, though it omits return-value details, which would be helpful but not essential given the low complexity.

  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 description covers projectRoot 100%, so the description does not need to add parameter details. It does not elaborate beyond the schema, but the baseline of 3 applies because the structured info is sufficient.

  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 uses a specific verb ('Check') and a clear resource ('uncommitted changes in default strings.xml files'). The qualifier 'without translating' distinguishes it from the sibling translation tools, making its purpose unmistakable.

  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 phrase 'without translating' implies this is a pre-translation check, but the description does not explicitly state when to use it versus alternatives like check_missing_languages or translate_all_modules. There is no direct 'use this instead of X' guidance, only an implicit context.

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

• translate_moduleA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses use of git diff and that translation targets all languages, but does not mention side effects like file modifications, commit behavior, or prerequisites.

  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?

  A single direct sentence with no fluff, front-loaded with the action and resource; every word 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?

  For a one-parameter tool with no output schema, the description adequately conveys the main behavior. It could mention side effects or error conditions, but given the simplicity it is complete enough.

  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 covers modulePath fully, but the description adds meaning by explaining that the module's default strings.xml is the target and that git diff is used, clarifying the purpose beyond the 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 states a specific verb ('Detect... and translate') with a precise resource ('specific module's default strings.xml'), clearly distinguishing it from sibling 'translate_all_modules'.

  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 context implies this is for a single module versus 'translate_all_modules', but it does not explicitly state when not to use it or compare with 'check_missing_languages' or 'create_and_translate_missing_languages'.

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