Server Quality Checklist

Tool Scores

• delete_recipeA
  3.9/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 the burden. It explicitly discloses the irreversible nature of the operation ('This cannot be undone'), which is a critical behavioral trait. It doesn't mention other side effects, but for a simple delete this is valuable and above baseline.

  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 two short, front-loaded sentences. The first sentence states the action, and the second reinforces permanence. While slightly redundant, it is concise and free of fluff, earning a high score.

  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 one-parameter delete tool with an output schema present, the description covers the essential purpose and the key risk (permanence). It doesn't address edge cases like non-existent recipes, but the output schema likely handles return behavior. Overall, it is sufficiently complete for the tool's simplicity.

  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 has 100% coverage for recipe_id, so the baseline is 3. The description adds no additional meaning about the parameter (e.g., where to find the ID, constraints, or how it's used). The schema itself only says 'Recipe id', which is minimal but sufficient per the coverage guideline.

  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 'Permanently delete a recipe', using a specific verb ('delete') and resource ('recipe'). This distinguishes it from sibling tools like search_recipes, get_recipe, create_recipe, and update_recipe.

  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 when a recipe needs to be removed, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., update_recipe for deactivation) or any exclusions. It's not misleading, but the context is only implied.

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

• search_recipesA
  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 transparency burden. It discloses that results are compact hits with only id, name, description, and keywords, so the agent knows not to expect full recipe details. This is a meaningful behavioral trait. It doesn't mention pagination or random ordering, but those are visible in the schema.

  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 short sentences, front-loaded with the primary action and immediately providing the key return shape and a navigational pointer to get_recipe. Every word earns its place with no redundancy.

  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 output schema exists and schema descriptions cover all parameters, the description is sufficiently complete. It adds the essential context that results are compact and that full details require a follow-up get_recipe call. It would benefit from noting the pagination behavior, but the schema already specifies page/page_size.

  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 description does not need to explain each parameter. The description adds no additional parameter-specific semantics beyond noting the returned id, which can be used with get_recipe. This meets the baseline but does not add extra value.

  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 and resource combination ('Search recipes') and clearly distinguishes the tool from get_recipe by noting it returns only compact hits and that full details require get_recipe. It is immediately clear this is the recipe search entry point.

  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 explicitly tells the agent to use get_recipe with an id from the result to read steps and ingredients, which outlines the intended workflow. It does not explicitly mention when not to use this tool or compare with other search siblings, but the search-vs-get distinction is clear.

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

• create_keywordA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description discloses the critical behavioral aspect that Tandoor lacks duplicate detection and that duplicates persist indefinitely. This goes beyond the schema and helps the agent understand the consequences, though it doesn't cover all potential outcomes.

  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, no filler. The purpose is immediately stated, and the warning is a valuable addition without bloat.

  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 key duplicate risk, and the output schema covers return values. For a simple creation tool with an output schema, this is nearly complete, though it could mention auth or error cases.

  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 coverage is 100% with clear descriptions for name and description, and the description doesn't add parameter-level detail. 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?

  The description opens with a specific verb-resource pair ('Create a new keyword (tag)') and adds a distinct warning that differentiates it from the search_keywords sibling, making the tool's 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs 'Search first,' telling the agent to use a search tool before this create tool to avoid duplicates. This provides clear usage context and implies the alternative (search_keywords).

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

• create_unitA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses a key behavioral trait: no duplicate detection, so duplicate units persist silently. This adds significant context beyond the basic 'create' action, though it doesn't cover other potential behaviors like permissions or failure modes.

  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 concise sentences deliver purpose, usage guidance, and a concrete example. Every sentence adds value with 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 simple create tool with an output schema, the description covers purpose, usage guidelines, and a critical risk. The presence of an output schema means return values need not be described, making this 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 coverage is 100% for all parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already specifies for name, description, and plural_name.

  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 'Create a new unit of measure' with a specific verb and resource, distinguishing it from sibling tools like search_units and other create_* tools.

  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 instructs to 'Search first' and 'List the units first', providing the alternative action and reasoning—'Tandoor has no duplicate detection'—which gives clear when-to-use guidance.

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

• get_recipeA
  4.5/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the burden. It discloses that the tool returns entity ids necessary for preserving related data during updates, which is valuable behavioral context. While it doesn't mention error handling or other traits, it adequately covers the key read-only semantics and the importance of preserving ids.

  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: the first sentence states the core function, the second provides essential usage guidance. No wasted words.

  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 simple read tool with one parameter and an output schema, the description covers the essential context: what is returned, why it matters, and how it relates to update_recipe. The presence of an output schema handles return value details.

  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 already fully describes the sole parameter (recipe_id) with 100% coverage, so the description doesn't need to add much. It doesn't go beyond the schema, but the baseline of 3 applies given high 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 clearly states the tool's function: 'Read one recipe in full: steps, ingredients, and all entity ids.' This specific verb+resource+scope distinguishes it from siblings like search_recipes (search) and update_recipe (write).

  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?

  Explicit guidance is provided: 'Always call this before update_recipe.' This directly tells the agent when to use the tool and implies it is a prerequisite for updates, with further instruction on passing ids back.

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

• search_keywordsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It explains key behaviors: listing all when queries omitted, hierarchical tree structure, and the meaning of 'full_name'. It does not mention pagination limits or read-only nature explicitly, but those are implied and partially covered by schema.

  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 main action. Every sentence is informative: purpose, structure/path, and use case. No redundant words or 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 two-parameter tool with full schema coverage and an output schema, the description fully covers the operational context: what it does, when to use it, and the tree semantics. No gaps for an AI agent to invoke correctly.

  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 coverage is 100% with both parameters described. The description adds value by illustrating the tree structure and how 'full_name' reflects the path, which is not in the schema. It also reinforces the 'queries' null behavior by restating that omitting queries lists all, though schema already says this.

  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+resource: 'Look up keywords (tags) by name, or list them all.' It clearly differentiates from sibling tools like create_keyword and other search tools by focusing on read/lookup behavior. The tree/path explanation adds precise scope.

  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 clear context: use without queries to list existing tags and align vocabulary. However, it does not explicitly state when NOT to use this tool or mention alternatives like search_foods/search_units, so it lacks explicit exclusions.

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

• search_foodsA
  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 reveals ranking by similarity with potential unrelated tail results, advises selecting the exact ingredient entry (e.g., 'Parmesan' over 'Parmesankäse'), explains the food tree path in 'full_name', and notes the rarely useful empty-query listing behavior.

  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 yet rich: about six sentences, front-loaded with purpose, and every sentence contributes unique guidance (ranking, selection, examples, tree structure, empty query). No filler or redundancy.

  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 presence of an output schema and the absence of annotations, the description fully covers essential aspects for a search tool: purpose, ranking behavior, selection tips, tree structure, and parameter use. It leaves no significant gaps for an agent to misuse the 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?

  Schema coverage is 100% and parameter descriptions already explain the queries and limit. The description adds practical semantic value with the example '100 g geriebener Parmesan' -> query 'Parmesan', clarifying how to think about query terms, which goes 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 opens with a specific verb ('Look up') and resource ('foods (ingredients)'), and adds batch capability ('all of a recipe's ingredients at once'). This clearly distinguishes it from sibling search tools like search_recipes and search_units, which target different entity types.

  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 gives clear usage guidance: search for the ingredient rather than the whole written line, and prefer exact ingredient names. It also warns that omitting queries lists foods, which is rarely useful. However, it does not explicitly name alternative tools or state when not to use this tool, though the context is strong.

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

• create_recipeA
  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 explains the required id+name references, the silent empty-string rendering for out-of-range template indexes, the server's rejection of such indexes, and the zero-based per-step indexing behavior. This gives agents a precise mental model of how the tool behaves, including failure modes.

  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 long but every section earns its place: the lookup prerequisite, ingredient normalization rule, templating reference, critical out-of-range warning, and convention example. Headings and the CRITICAL callout make the dense information scannable and actionable.

  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 nested recipe/step/ingredient inputs, templating behavior, and no annotations, the description covers the essential operational details completely. It addresses the key gotchas an agent would face: entity lookup, zero-based indexing, scaling behavior, and silent failures. The output schema can handle return-value documentation, so its omission is not a gap.

  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 0% description coverage at the top level, but the description heavily compensates. It explains how to reduce ingredient lines, how to separate notes from food names, and every templating placeholder with examples. This adds substantial meaning that the schema alone does not convey.

  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 'Create a new recipe with all its steps and ingredients in one call,' using a specific verb and resource while clarifying the all-in-one scope. This clearly distinguishes it from siblings like update_recipe, delete_recipe, and get_recipe. The purpose is unmistakable.

  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: use this to create a full recipe after looking up foods, units, and keywords via the search tools. It does not explicitly mention alternatives like 'use update_recipe to modify an existing recipe,' but the create-oriented purpose and the prerequisite search steps provide strong usage guidance.

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

• update_recipeA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals the partial-update behavior, the destructive consequence of omitted steps ('an omitted step is deleted'), the zero-based indexing with silent empty-string rendering for out-of-range indexes, and the server's rejection of such indexes. It also explains Jinja templating, scaling behavior, and the convention for Jinja comments. This is exceptionally rich and transparent.

  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 long but every section earns its place. It is front-loaded with the most important behavior (partial update, step replacement) then proceeds to templating details, with clear headers like 'STEP TEMPLATING' and 'CRITICAL'. The examples are concrete and useful for an AI agent. No filler or repetition of the schema is present.

  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 tool's high complexity (nested update object, step/ingredient lifecycle, templating), the description covers all major hazards: partial updates, step replacement, id handling, index counting, silent errors, and scaling. The presence of an output schema means return values need not be explained. No critical behavioral gaps remain that would cause an agent to misuse the tool.

  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 description adds significant meaning beyond the schema, especially for the 'update' object and its nested steps. It explains that a step without an id is created as new, an omitted step is deleted, and the same holds for ingredients within a step. It details how template placeholders work ({{ ingredients[0] }} etc.), indexing semantics, and the critical silent-failure mode. Even with 50% schema coverage, the description compensates where it matters most, making the tool safe to invoke correctly.

  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 'Update an existing recipe. Only the fields you set are changed; the rest of the recipe is read and written back unchanged.' This clearly states the verb (update), resource (recipe), and a critical scope nuance (partial update) that distinguishes it from create/delete/get siblings. It also explicitly contrasts with get_recipe and the replacement semantics for steps, 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 clear context for when to use this tool, such as 'Call get_recipe first and pass back every step you want to keep' and explains that passing 'steps' replaces the entire step list. It does not explicitly name alternatives or state when not to use it, but the guidance is concrete and actionable, meeting the 'clear context, no exclusions' level.

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

• create_foodA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses a key behavioral trait: Tandoor lacks duplicate detection, so creating a duplicate will silently succeed. It also adds domain-specific rules about naming, which are not visible in the schema or 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 sentences with no fluff. The first sentence is the core purpose; the second packs essential usage warnings and naming rules. Every word earns its place.

  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 simple create tool with an output schema, the description covers all necessary context: what it does, how to avoid duplicates, and naming conventions. It is fully sufficient for an agent to use it correctly without additional info.

  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 description coverage is 100%, so baseline is 3. The description adds meaning to the 'name' parameter by specifying it should be a plain noun and not a prepared form, and suggests that preparation belongs in the note (likely the 'description' parameter). This adds value 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?

  Clearly states 'Create a new food (ingredient)' with a specific verb and resource. The description distinguishes itself from siblings by emphasizing the need to search first due to missing duplicate detection, making it clear this is for creating new entries only.

  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?

  Explicitly instructs 'Search first' and explains why (no duplicate detection), effectively guiding the agent to use search_foods before invoking this tool. Also provides naming conventions to avoid incorrect usage, such as storing plain nouns rather than prepared forms.

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

• search_unitsA
  4.9/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. It discloses that omitting queries returns the complete (short) vocabulary, and that unit names are case/locale-sensitive ('g' and 'Gramm' are separate), with invisible consequences for choosing the wrong one. This is key behavioral context beyond the schema.

  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, no filler. The first states the purpose, the second gives a usage recommendation and a concrete warning. Every sentence contributes.

  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 schema covers parameter descriptions and the output schema exists, so no return format explanation is needed. The description covers the edge case (no queries) and the ambiguity pitfall. For a simple lookup tool, this is fully complete.

  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 schema already documents both parameters (limit and queries). The description adds meaningful guidance: omitting queries returns the full vocabulary and is recommended when unsure. It reinforces and extends the schema's 'Omit to list everything' with practical advice.

  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 units of measure, or list them all,' which clearly identifies the resource (units of measure) and the two supported actions (lookup and list). This distinguishes it from sibling tools like create_unit and search_foods.

  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?

  Explicitly advises to call without queries to list the entire vocabulary when unsure, rather than guessing a name, and warns about Tandoor's 'g' vs 'Gramm' separation. This provides a clear decision rule and alternative, though it doesn't name specific sibling tools.

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