Server Quality Checklist

Tool Scores

• lint_rtl_pathA
  3.6/5.0
  Behavior3/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 a useful behavioral detail: skipping node_modules and build output. However, it does not mention the return format, error handling, or whether the operation is read-only (though 'check' implies it).

  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 long: the first conveys the core purpose, the second adds a key behavioral note about skipping node_modules/build. No fluff, clearly 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?

  For a low-complexity read-only check tool with no output schema, the description covers the essential aspects: purpose, target, and a significant behavioral exception. It omits the return format but that is a minor gap for this simple tool. Overall it is sufficiently complete.

  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%, and the schema already explains both parameters clearly (path and baseDir with enum). The description adds no extra semantic information 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Check') and the resource ('a file or a whole directory on disk'), and it specifies the focus on right-to-left layout problems. While it distinguishes from sibling tools by scope (on disk vs. code), it does not explicitly name the alternatives.

  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 'on disk' implies this is for files/directories rather than code snippets, but there is no explicit statement about when to use this tool versus siblings like lint_rtl_code. No exclusions or alternative guidance are provided.

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

• detect_directionA
  4.2/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 that the tool is non-mutating ('Report') and provides the decisioning outcome ('what to set dir to'). It doesn't describe edge cases or return format, but for a simple inspection 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?

  Two sentences, directly front-loaded with the action and output, and no wasted words. Every clause adds value.

  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, with one parameter and no output schema. The description covers purpose, when to use, and what is reported. It lacks exact return format but that is not critical for selection and invocation. Adequate for a simple detection 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 schema fully documents the one parameter ('text' with description), and the tool description adds context about use cases (label, database field, user content) but no additional parameter-level semantics. Baseline 3 is appropriate given 100% schema coverage.

  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 ('Report') and defines the resource (a string) and the exact output categories (right-to-left, left-to-right, mixed, neutral). It also adds 'what to set dir to', clearly distinguishing this detection tool from siblings like lint_rtl_code and normalize_arabic.

  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?

  Explicitly states when to use the tool: 'Use it when you need to decide the direction of a label, a database field or a block of user content.' It gives clear context but does not provide exclusions or alternatives, though the sibling tools are obviously different, so this is sufficient.

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

• lint_rtl_codeA
  4.2/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 burden. It discloses that the tool returns each finding with the logical replacement, which is a key behavioral detail. It does not mention side effects, but being a linting tool, it is implicitly read-only. The description adds useful behavioral context beyond a simple verb.

  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 main purpose and includes concrete examples (file types, problem types, return value). Every sentence earns its place; no fluff.

  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 the tool has 3 params, no output schema, and no annotations, the description covers the main usage, input scope, and return format. It could specify the output structure in more detail, but it gives enough for an agent to understand what to expect. Compared to the tier examples, this is above midpoint.

  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 covers 100% of parameters with descriptions. The tool description adds no additional parameter-specific semantics beyond mentioning 'snippet' and 'logical replacement', which are already implied. Baseline 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 checks CSS/HTML/JSX/TSX for RTL layout issues, listing specific problem categories (physical CSS properties, directional Tailwind utilities, dir problems). It is a specific verb+resource combination that distinguishes it from siblings like lint_rtl_path or detect_direction.

  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 explicit context: 'Use this before handing RTL-facing markup back to the user.' This implies when to use it but doesn't explicitly mention alternatives or exclusions, though sibling tools have distinct names that imply different purposes.

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

• normalize_arabicA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full responsibility for disclosing behavior. It warns that the output is not suitable for display, which conveys the lossy/destructive nature of normalization. It does not mention the optional transformation flags or their implications, but the schema covers those; the description adds the key caveat.

  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, immediately states the core function, and provides a clear use-case disclaimer. No redundancy or 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 tool has five parameters, all documented in the schema, and the description gives the essential context and usage caveat. It does not explicitly state the return value, but that is inferable from the normalization concept and the schema. The sibling tools are different enough that no confusion arises.

  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 covers 100% of parameters with descriptions, so baseline is 3. The description reinforces the overall purpose but does not add parameter-specific details beyond what the schema already states. The mention of stripping diacritics and tatweel corresponds to the default behavior, aligning with the text 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 normalizes Arabic text, specifically stripping diacritics and tatweel and folding alef variants. It distinguishes itself from sibling lint/detection tools by focusing on normalization for matching and deduplication.

  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?

  It explicitly provides usage guidance: use for search keys, deduplication, and matching, and explicitly warns never for display. This is a clear when-to-use and when-not-to-use directive, though it does not reference sibling tools, they are unrelated enough that no alternative is implied.

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