Server Quality Checklist

Tool Scores

• lookup_wordA
  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. It discloses that matching is case- and diacritic-insensitive and that results are labeled with roots. It implies a read-only operation but does not mention pagination, error handling, or rate limits—though these are less critical for a simple lookup and an output schema is present.

  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?

  Three sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, matching behavior, and usage guidance. No redundant phrasing.

  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; the description covers purpose, matching nuances, and an alternative tool. The presence of an output schema means return values are already defined. It lacks explicit notes on no-match behavior, but this is a minor gap given the output schema.

  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 0%, so the description must compensate. It clarifies 'word' as a surface form or lemma, but does not explain the 'limit' parameter beyond its default value. This partial coverage earns a mid-range score.

  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: 'Look up a surface Arabic word (any inflected form or lemma).' It distinguishes from siblings by mentioning that lookup_root is for root-based searches and explicitly notes this tool is 'Good when the user gives a word but not the root.'

  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?

  Provides explicit guidance: use when the user supplies a word but not the root, and pivot to lookup_root when sibling words are desired. The mention of lookup_root as an alternative is a clear when-not condition, though search_meaning is not explicitly excluded.

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

• lookup_rootA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full transparency burden and excels. It discloses normalization of diacritics and letter-variants, the three distinct data sources, and the critical vocalization contrast ("Input is diacritic-insensitive; output is not"), which are essential behavioral details beyond what any schema could convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is detailed but well-organized, with the primary statement first and supporting details in a scannable list. It avoids redundancy, though the list of letter variants (ا/أ/إ/آ, ي/ى, ه/ة) could be condensed without loss.

  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 description fully equips the agent by explaining the three result sources, the shape of verb entries (tense-availability flags in `extra`), and the vocalization behavior. Since an output schema exists, the description doesn't need to detail the return structure further; it covers input, processing, and output expectations.

  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 has zero description for the `root` parameter, but the description compensates fully with concrete examples of accepted forms ("كتب", "ك ت ب", "ك-ت-ب", with diacritics) and explains the normalization behavior. This gives the agent complete understanding of what the parameter accepts.

  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 "Look up an Arabic root and return all dictionary entries under it," which names a specific verb and resource. It further distinguishes from siblings by clarifying root-based lookup versus word-based lookup, making the 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 a clear trigger: "Use this when the user has already identified the root" and a secondary case: "or when you want to see all sibling words for a lemma." However, it does not explicitly mention alternatives like lookup_word or search_meaning, so it lacks explicit when-not-to-use guidance.

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

• search_meaningA
  4.7/5.0
  Behavior4/5

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

  Although no annotations exist, the description discloses useful behavioral traits: results are 'ranked by relevance' and each carries its root, enabling chaining to `lookup_root`. It also clarifies search corpora per language. It doesn't explicitly state read-only nature, but for a search tool this is implied; still, with no annotations, full burden rests on the description, which meets most expectations but omits edge-case behavior like limits or error handling.

  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 three sentences: a one-line purpose, a usage condition, and language/search behavior. It is front-loaded with the core action, and every sentence contributes to understanding selection or invocation. No unnecessary detail.

  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 output schema exists and the tool is a straightforward search with one required parameter, the description covers usage, language options, result ranking, and the appropriate next step. It lacks mention of `limit`, but that's a schema default, and no other contextual gaps are apparent. The description is comprehensive for a search tool.

  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?

  With 0% schema description coverage, the description compensates by explaining `query` (concept in English or Arabic) and `lang` (English Lane glosses vs Arabic arramooz definitions). It does not elaborate on `limit`, but the parameter is self-explanatory and has a default in the schema. The description adds meaningful context for the two core parameters.

  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 'Full-text search over dictionary meanings,' which clearly identifies the tool's function and resource. It distinguishes from sibling lookup tools by focusing on searching meanings, not exact-word lookup, and references calling `lookup_root` as a follow-up. This provides a specific verb and resource scope.

  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 states when to use: 'Use when the user asks "what's the Arabic root for X?" or gives a concept in English or Arabic.' It also explains the `lang` parameter's role in choosing between English glosses and Arabic definitions, and even directs follow-up to `lookup_root`. This is clear contextual guidance without needing to mention exclusions.

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