Server Quality Checklist

Tool Scores

• get_keywordsC
  2.6/5.0
  Behavior1/5

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

  With no annotations, the description must disclose behavioral traits, but it offers none. It does not mention return format, whether results are recursive, or how the parameters affect output. This is a significant gap for a tool with no output schema.

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

  Conciseness3/5

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

  The description is a single short sentence with no waste, but it is under-specified. While concise, it omits critical context that would make it genuinely useful, so it meets only the minimum bar.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema and no annotations, the description should explain what the tool returns and how the three optional parameters interact. It does not, leaving the agent with incomplete information for a three-parameter 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?

  Schema description coverage is 100%, so the parameters are already documented (root, tree, query). The description does not add meaning beyond 'list or search,' but the baseline of 3 is appropriate because the schema handles parameter semantics.

  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 uses specific verbs ('List or search') and identifies the resource ('keywords'), which distinguishes it from sibling tools like get_recipes or get_foods. It lacks context on what keywords represent, but the core action is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, or how the parameters (root, tree, query) should be chosen. The description merely states the action without any contextual usage advice.

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

• get_foodsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'list or search' and fails to explain hierarchical behavior (root vs tree), pagination, sorting, or return format. This is a significant gap for a tool with three optional parameters.

  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 a single, front-loaded sentence that efficiently communicates the core action. It is appropriately terse, though it sacrifices some informational richness for brevity. It earns a 4 for being concise and to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool lacks annotations and an output schema, and the description is too brief to provide sufficient context. It does not explain the hierarchical structure, search behavior, or expected results, leaving the agent without enough information to confidently invoke the tool in all scenarios.

  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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal meaning beyond the schema, only implying that 'query' is for searching while root/tree are for listing. No additional semantics are provided.

  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 'List or search for foods' clearly states the tool's action (list/search) and resource (foods), distinguishing it from sibling tools like get_recipes and get_meal_plans. It lacks explicit differentiation, but the resource name is specific enough to avoid confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, nor any context for when to use 'list' vs 'search' or how the root/tree parameters should be used. The description merely states the basic action without situational direction.

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

• get_recipesC
  2.9/5.0
  Behavior2/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 only says 'search... based on various criteria' without disclosing behavioral traits like read-only status, filtering semantics (match ANY), result limits, or pagination. The description adds minimal value beyond the name.

  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 sentence, front-loaded with the action and resource. It wastes no words, though 'various criteria' is vague. Still, it's highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description should clarify return values and usage context. It fails to explain what the search results look like, any default behavior, or how criteria combine. The tool has 5 optional parameters, so the description is insufficiently complete for an agent to fully understand the tool's 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?

  Schema description coverage is 100%, so the baseline is 3. The description's 'various criteria' is generic and adds no specific meaning beyond the schema, but the schema fully documents all parameters, so no compensation is needed.

  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 tool searches for recipes in Tandoor, using verb 'search' and resource 'recipes'. It distinguishes from sibling get_recipe_details by implying list/search functionality rather than fetching a specific recipe's details, though it could be more explicit about the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like get_recipe_details. There's no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.

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

• create_tandoor_recipeB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. 'Create a new recipe' implicitly indicates a write/mutation operation, but it does not disclose potential duplicate behavior, permission requirements, or whether the operation replaces existing data. This is a minimal disclosure with notable gaps.

  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 with no filler or redundant content. Every word contributes to the core purpose, making it appropriately concise and easy to parse.

  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 rich parameter schema and straightforward create operation, the minimal description is sufficient for basic invocation. However, the absence of output or behavior details (e.g., what is returned, how duplicate names are handled) leaves clear gaps, so it is minimally viable rather than 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?

  The input schema provides full descriptions for all 5 parameters (100% coverage), so the description does not need to repeat parameter details. The description adds no extra semantic information beyond what the schema already supplies, resulting in a baseline score.

  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 uses the verb 'Create' and specifies the resource 'a new recipe in Tandoor,' which clearly differentiates it from sibling tools like 'create_tandoor_meal_plan' and read-only tools like 'get_recipes.' However, it lacks additional scope or constraints that would push it beyond a clear, minimal statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description simply states what it does without contextualizing its place among the sibling tools.

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

• get_unitsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits, but it only says 'List or search for units.' It does not state whether this is a read-only operation, how the query parameter affects results, or what the response contains. This is a significant gap for an unannotated tool.

  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 directly states the action and resource. It is efficient with no wasted words, earning a high score for conciseness.

  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 tool is simple (one optional parameter, no output schema), and the description provides the core function. However, it does not explain what units are, how results are structured, or any query behavior. Given the lack of annotations and output schema, there are clear gaps, but the description is minimally viable.

  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 full description for the only parameter 'query' ('Optional search term for unit name.'). The description adds nothing beyond aligning 'search' with the query parameter, so the baseline of 3 is appropriate given the high schema coverage.

  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 uses a specific verb 'List or search' with a clear resource 'units', distinguishing it from sibling tools that focus on recipes, foods, meal plans, etc. However, it does not elaborate on what 'units' refers to, which causes slight ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that for other entity types (e.g., foods, keywords) you should use those specific tools, nor does it state any preconditions. The only implied usage is 'when you need units', which is not explicit.

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

• add_shopping_list_itemB
  3.3/5.0
  Behavior2/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 only states that food/unit names or IDs are accepted, but does not disclose side effects such as duplicate handling, permission requirements, or whether the operation appends or merges. The mutation behavior is implied but not elaborated.

  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 communicates the core action and key flexibility (names/IDs) without redundancy or filler. It earns its place with no unnecessary words.

  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 simple add operation, and the schema supplies parameter details. However, it lacks guidance on use cases (e.g., when to prefer update) and behavioral caveats, making it incomplete for a mutation tool with no annotations or output schema. The absence of return-value information is acceptable given no output schema, but the missing usage context lowers the score.

  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%, so the baseline is 3. The description adds minimal value beyond the schema by reiterating that food/unit can be names or IDs, which is already in the schema. No additional parameter insights or cross-parameter relationships are provided.

  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 ('Add') and a clear resource ('item to the shopping list'), which precisely conveys the action. It also distinguishes itself from sibling tools like update_shopping_list_item and remove_shopping_list_item by indicating a create operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  The description implies use for adding new items but provides no explicit guidance on when to use it vs alternatives (e.g., update for existing items, remove for deleting). No exclusions or alternative tool references are mentioned, leaving the agent without clear decision criteria beyond the verb 'add'.

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

• remove_shopping_list_itemB
  3.3/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 disclose behavioral traits. The description only says 'Remove an item' without mentioning whether the action is permanent, whether it can be undone, what happens if the item_id is invalid, or any side effects. This is a mutation tool, and the description lacks critical safety or reversibility information.

  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, clear sentence with no wasted words. It is appropriately sized for a tool with a single parameter and a simple action, achieving maximum conciseness without unnecessary filler.

  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?

  For a tool with one parameter, no output schema, and no annotations, the description is minimally adequate but lacks behavioral context. It covers the core action and parameter, but fails to disclose consequences of deletion, error handling, or any prerequisites. Given the simplicity, this is a borderline score.

  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 provides 100% coverage by describing item_id as 'The ID of the shopping list item to remove.' The description adds no additional meaning beyond that. Per the rubric, with high schema coverage, a 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 clearly states the action (Remove) and the resource (an item from the shopping list). This distinguishes it from sibling tools like add_shopping_list_item and update_shopping_list_item, which perform different operations on the same list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. While the name and description imply the action, no context is provided about prerequisites (e.g., item must exist), when removal is appropriate, or when using update_shopping_list_item would be better instead.

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

• get_recipe_detailsA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Retrieve the full details' without detailing error handling (e.g., 404 for missing recipe), response format, authentication requirements, or any side effects. For a read operation, some of this is implicit, but the description is thin.

  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 with no redundant information. It efficiently communicates the tool's purpose without wasting words.

  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?

  This is a simple get-by-id tool with one parameter and no output schema. The description explains the basic purpose but does not specify what 'full details' includes or behavior on missing IDs. Given the absence of an output schema, some additional detail about the return value or error conditions would improve completeness.

  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% for the single parameter recipe_id, so the schema already provides the meaning. The description adds no additional parameter semantics beyond reiterating that the recipe is specific. 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 action (retrieve), resource (full details of a specific recipe), and scope (specific, implying by ID). This distinguishes it from sibling tools like get_recipes, which likely lists recipes, and create_tandoor_recipe, which creates.

  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 user needs full details of a specific recipe, but it does not explicitly state when to use this tool versus alternatives like get_recipes. No exclusion criteria or alternative tools are mentioned, leaving the usage context to be inferred.

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

• get_shopping_listA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it clarify what 'current' means (e.g., active list vs. recent items). It also does not describe any return format or side effects, leaving important context unstated.

  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 immediately signals the tool's purpose. It contains no redundant or irrelevant information, earning full marks for efficiency.

  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?

  For a simple read tool with one optional parameter, the description is adequate but not comprehensive. The lack of annotations and output schema places more burden on the description to clarify ambiguities like 'current' and the meaning of returned items. Some useful details are missing, so it remains a minimum-viable description.

  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 for the single 'checked' parameter, including a description and enum values. The description adds no additional parameter semantics 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 uses the specific verb 'Retrieve' with a clear resource 'shopping list items', making its read-only purpose explicit. This differentiates it from sibling tools that mutate the list (add, update, remove).

  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 a use case (obtaining the current shopping list), but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. The sibling names make the distinction obvious, but the description itself does not articulate it.

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

• update_shopping_list_itemA
  3.5/5.0
  Behavior2/5

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

  There are no annotations, so the description carries full responsibility for behavioral disclosure. It says 'Update' but does not clarify partial-update semantics (e.g., whether only provided fields are changed), error handling for nonexistent items, or any side effects. This is a significant gap for a mutation tool.

  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, focused sentence that is front-loaded with the core action. Every word contributes to the purpose, and there is no padding or redundancy.

  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 tool's complexity (5 parameters, no annotations, no output schema), the description provides only minimal context. It states the purpose and gives examples but omits critical details like partial update behavior or response format. It is minimally viable but not comprehensive.

  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 baseline is 3. The description's mention of 'check/uncheck' and 'change amount' loosely maps to the 'checked' and 'amount' parameters but adds no new meaning beyond the schema descriptions. It does not compensate for any missing schema info.

  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 a specific verb ('Update') and resource ('existing shopping list item'), with concrete examples ('check/uncheck, change amount'). This distinguishes it from sibling tools like add_shopping_list_item, remove_shopping_list_item, and get_shopping_list.

  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 modifying existing items but does not provide explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites. The examples hint at typical use cases but lack direct comparative guidance.

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

• get_meal_plansA
  3.6/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 behavioral disclosure burden. It indicates a read-only operation ('Retrieve'), which is a key behavioral trait. However, it does not mention potential limitations such as pagination, rate limits, authentication requirements, or what happens when no filters are applied (e.g., returns all entries). The description is brief but not misleading.

  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 states the action, resource, and optional filters. There is no redundant information or filler, making it appropriately concise and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema and no annotations, so the description should provide more context about return values or entry structure, but it does not. It omits what a 'meal plan entry' contains, how results are ordered, or any response details. The description is sufficient for a simple read, but given the lack of structured metadata, it leaves agents guessing about the tool's output.

  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 descriptive parameter docs for to_date, from_date, and meal_type_id. The description does not add meaningful detail beyond the schema; it just summarizes the optional filters. Baseline 3 is appropriate because the schema already fully documents 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 uses a strong, specific verb ('Retrieve') and specifies the resource ('meal plan entries from Tandoor'), along with optional scope (date range and meal type). This clearly distinguishes it from sibling tools like get_meal_types (retrieves meal types, not plans) and create_tandoor_meal_plan (writes, not reads).

  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 use when retrieving meal plan entries, and the optional filters hint at flexible scenarios. However, it does not explicitly state when this tool should be used instead of siblings (e.g., get_meal_types for meal types), nor does it mention exclusions or prerequisites. The context is implied rather than explicit.

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

• create_tandoor_meal_planA
  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 carries the full burden of behavioral disclosure. It only states 'Add one or more recipes' without mentioning any potential side effects, error conditions (e.g., invalid meal type, duplicate entries), or whether the operation overwrites existing entries. This is a significant gap for a mutation tool.

  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 with no filler. Every phrase is relevant to the tool's core action and constraints.

  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?

  For a simple add operation with fully described parameters and no output schema, the description provides the essential purpose. However, given there are no annotations, it would benefit from noting prerequisites (e.g., meal type must exist) or expected behavior, but these gaps are partially covered by the schema. The description is minimally viable but not comprehensive.

  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 descriptions for all six parameters. The tool description adds only that it adds 'one or more recipes' for a 'specific date and meal type', which slightly reinforces the recipes array and start_date/meal_type parameters, but does not add meaningful syntax or format details beyond the schema. 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 uses a specific verb ('Add') and clearly identifies the resource ('recipes to the Tandoor meal plan') with the key constraints of date and meal type. This distinguishes it from siblings like 'get_meal_plans' (read) and 'create_tandoor_recipe' (add recipe).

  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 is clear: use this when you need to add recipes to a meal plan for a specific date and meal type. It implies a write operation, distinct from read-only siblings. No explicit exclusions or alternatives are mentioned, but the purpose is specific enough.

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

• get_meal_typesA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description itself must convey behavioral traits. 'List' clearly implies a read-only operation with no side effects. It adds context by specifying 'all available' and 'in Tandoor'. There is no hidden behavior to disclose given this is a zero-parameter read tool.

  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, clear sentence that conveys the full purpose without unnecessary words. 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?

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description fully covers what the tool does. It tells the agent that the tool returns a list of meal types, which is sufficient for correct invocation.

  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, and the schema coverage is 100% trivially. The description is not required to explain any parameters because there are none. This matches the baseline for 0-parameter tools.

  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 the specific verb 'List' and identifies the resource 'meal types' within Tandoor. It clearly distinguishes this tool from siblings like get_recipes or get_meal_plans by focusing on meal types.

  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 the agent needs to enumerate available meal types, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No sibling tool is mentioned as an alternative, leaving the guidance implicit.

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