Server Quality Checklist

Tool Scores

• get_recipeA
  4.4/5.0
  Behavior5/5

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

  The description goes far beyond the annotations by disclosing detailed behavioral edge cases: rescaling rules (eggs stay whole, pours/cuts may halve, unmultipliable fields are flagged), behavior when no serving count is published, how absent sections are reported, the meaning of empty ingredient lists, and the null-versus-zero convention. These are exactly the caveats an agent needs to interpret results correctly.

  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 long but well-structured: the core purpose is front-loaded, followed by id provenance, rescaling behavior, and result interpretation rules. Each sentence contributes a distinct behavioral or usage nuance. A few sentences could be tightened, but for a tool with this many edge cases the length is justified.

  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 rich output schema and annotations covering read-only, idempotent, and non-destructive behavior, the description covers everything an agent needs to call the tool correctly and interpret its results: identity constraints, rescaling semantics, section omission behavior, null-versus-zero conventions, and the significance of empty ingredient lists. No critical information is missing.

  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 each parameter already has a detailed description with defaults and constraints. The tool description adds minimal parameter-level meaning beyond the schema, mostly restating that servings triggers rescaling and sections selects output. This matches the baseline of 3 for 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 opens with a specific verb and resource ('Read one recipe in full') and enumerates what is returned: ingredients, steps, yield, times, rating, nutrition. It also differentiates from the sibling search_recipes by requiring that 'id' come from it, so there is no ambiguity about which tool does what.

  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 operational guidance: the id must originate from search_recipes, servings can be passed to rescale, and sections controls what is returned. It also explains why unknown ids are refused. It does not explicitly name when to prefer a sibling such as scale_ingredients or compare_recipes, but the context is strong enough that an agent will know when to use this tool.

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

• compare_recipesA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnly, idempotent, and openWorld annotations, the description discloses meaningful behavioral traits: no ranking among versions, no shared score because some sources lack ratings, rescaled servings for comparability, and an explicit policy that a single matching source is shown rather than presenting a partial comparison. These details are not visible in the schema and materially shape output expectations.

  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 front-loaded with the core purpose and each subsequent sentence earns its place by explaining comparison behavior, non-ranking, rating limitations, and single-source fallback. It is prose-style but compact and free of pointless decoration; every sentence contributes to correct invocation and interpretation.

  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?

  With an output schema present and a full input schema, the description covers the essential behavioral context: what comparison means, how rescaling works, what is reported, what is not compared, and how edge cases are handled. An agent has enough information to select this tool and set expectations for the response without guessing.

  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 reinforces the purpose of servings rescaling and the idea of matching sources, but it does not add significant parameter-level meaning beyond what the schema already documents. It earns the baseline without exceeding it.

  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 and resource: 'Take a dish and show how each source writes it, side by side.' This unambiguously identifies the tool as a multi-source comparissor and distinguishes it from sibling tools like get_recipe or scale_ingredients by emphasizing side-by-side comparison and differing source treatments.

  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 for when this tool is appropriate: when an agent wants to see how different sources treat the same dish. It also explains the all-sources-by-default behavior and the single-source fallback. It does not explicitly name sibling alternatives or say 'use get_recipe instead for a single recipe,' but the comparative purpose is clear enough to infer the boundary.

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

• scale_ingredientsA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and idempotentHint annotations, the description discloses rich behavioral traits: rounding rules ('an egg stays whole', 'a spoonful shrinks into the smaller spoon'), the exact 'scaling' status values ('scaled', 'rounded', 'unscaled'), and the constraint that no quantity is converted between measuring systems. This provides significant added value for predicting tool 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 structured with a clear opening statement of function, followed by input guidance, then detailed behavioral rules. Every sentence contributes unique information—from language support to output scaling categories to the no-conversion constraint—without unnecessary repetition. It is detailed yet efficiently organized.

  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 complexity and the presence of an output schema, the description covers all essential aspects: language handling, parameter alternatives, rounding behavior, scaling statuses, and conversion constraints. The agent has enough information to select and invoke the tool correctly, and with the output schema available, return values do not need to be re-explained.

  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 describes all parameters with 100% coverage, including the factor/servings exclusivity. The description reinforces this relationship and adds context about output rounding, but it does not add substantial new meaning to individual parameters beyond what the schema provides. 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's purpose: 'Multiply a list of ingredient lines' in multiple language contexts. This specific verb-resource pairing distinguishes it from sibling tools like get_recipe, search_recipes, and compare_recipes, which focus on retrieval and comparison rather than scaling.

  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 explains the two input modes: give either 'factor', or 'from_servings' and 'to_servings', and clarifies that the factor is worked out from servings. It does not mention alternative tools or exclusions, but the context for using this scaling tool is clear and directly actionable.

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

• search_recipesA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, openWorld, idempotent), it reveals per-source language/count differences, the meaning of 'per_source', the possibility of reference pages, the fan_out union behavior, negation/allergy handling, and interleaved ordering. This is extensive behavioral disclosure that goes far beyond the structured metadata.

  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 front-loaded with the purpose and every sentence adds value, but it is a single dense paragraph that could benefit from logical section breaks (e.g., fan_out, per_source, limitations). Given the tool's complexity, the verbosity is justified, but structure could be improved.

  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 covers language differences, per_source failure reporting, false-negative warnings, page-type ambiguity, fan_out mechanics, negation handling, and ranking behavior. With an output schema present and annotations covering safety, it is remarkably complete for a complex 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?

  The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful extra context for query (sent as free text with no filtering), fan_out (additional wordings and union results), and sources (ids from per_source). It does not add much for limit_per_source, but the schema already explains it adequately.

  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 and resource: 'Search every recipe source this server reads, at the same time, for a dish or an ingredient, and get one merged list.' This clearly states the tool's function and differentiates it from the sibling get_recipe by noting that each row carries the id get_recipe takes, implying search is the discovery step.

  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 when to use get_recipe instead: 'open a row with get_recipe and read the ingredient list before calling it suitable.' It also explains when to turn fan_out off, and warns that a short list is not evidence. These are clear, actionable usage guidelines.

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