Server Quality Checklist

Tool Scores

• nutrition_detailA
  4.5/5.0
  Behavior4/5

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

  Discloses important behaviors: missing nutrients return null not 0, and cost per call. However, no annotations exist to cover safety or side effects. Lacks details on authentication or error handling, but sufficient for expected use.

  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?

  Description is well-organized with clear purpose, usage, and return details. While slightly long due to the nutrient list, it is efficiently structured and front-loaded. Every sentence adds value.

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

  Completeness4/5

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

  Given the tool has an output schema (not shown but mentioned), description explains return values. It covers parameter source, cost, and missing nutrient handling. Sufficient for a single-parameter look-up tool with no complex workflows.

  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 only says fdc_id is integer required. Description adds essential context: it is a USDA FoodData Central ID obtained from nutrition_search, which is critical for correct usage. With 0% schema coverage, description compensates well.

  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 it gets the full per-100g nutrition profile for one food using an fdc_id. Distinguishes itself from siblings like nutrition_search, nutrition_compare, and nutrition_recipe by specifying its unique role.

  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 tells when to use ('when user needs micronutrients beyond calories/protein/carbs/fat') and that fdc_id comes from nutrition_search. Also mentions cost per call, giving clear usage policy.

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

• nutrition_recipeA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It explains the scaling and summation logic. Discloses pricing but does not mention rate limits or error handling. Overall transparent for a pure computation 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?

  4 sentences, each valuable: purpose, usage examples, technical detail, parameter spec. Front-loaded with key info, 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 output schema exists, description covers purpose, usage, parameter, cost, and computation. Missing error scenarios but adequate for a single-param tool with good structure.

  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?

  Schema coverage 0% means description is crucial. It specifies ingredient list must contain fdc_id (int) and grams (float) pairs, min length 1, and weights in grams. This fully compensates for the vague 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 the tool sums nutrition across weighted ingredients, with specific verb 'Sum' and resource 'nutrition across a recipe'. It distinguishes from siblings (compare, detail, search) by focusing on aggregation.

  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 explicit use cases: meal planning, recipe analysis, combining ingredients. Mentions cost per call. Lacks explicit when-not-to-use or direct comparison to siblings, but usage context is clear.

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

• nutrition_searchA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so the description carries full burden. It discloses that results are 'ranked matches', lists returned fields, and mentions the cost ($0.001 per call). It does not mention any mutability, rate limits, or auth needs, which are less critical for a search 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?

  Front-loaded with the main purpose in the first sentence. The description is brief (5 sentences) and well-structured, with clear separation of parameter guidance. Every sentence adds value.

  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 (a free-text search with one required parameter) and the presence of an output schema (mentioned but not shown), the description is complete. It covers purpose, usage flow, cost, and parameter details, leaving no obvious gaps.

  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 input schema has 0% description coverage, so the description must compensate. It explains 'q' as 'Free-text food name' with examples, and 'limit' with default value (10) and valid range (1-50), adding significant meaning 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 clearly states it finds foods in the USDA FoodData Central database by free-text name and explains its primary use case: getting fdc_id for other nutrition tools. It explicitly distinguishes from siblings by positioning it as the first step.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use this FIRST when the user mentions a food by name', providing clear context for when to use it. It implies alternatives (other nutrition_* tools) but does not explicitly state when not 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.

• nutrition_compareA
  4.8/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 full burden. It discloses pricing ($0.003 USDC per call) and return format (full nutrition plus per-nutrient winners). However, it does not mention error handling or edge cases.

  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 with three sentences plus a parameter line. It front-loads the purpose, then gives usage guidance, then return and pricing. No wasteful content.

  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 has an output schema (likely detailed), the description adequately covers inputs, purpose, return summary, and pricing. It is complete for selecting and invoking the tool correctly.

  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, so the description must compensate. It does so by explaining that fdc_ids are USDA FDC IDs and must be between 2 and 5, adding critical meaning 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 clearly states the verb 'compare' with resource 'foods' and constraints '2 to 5'. It distinguishes from siblings by noting it's cheaper and clearer than calling nutrition_detail multiple times.

  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?

  The description explicitly states when to use ('when the user asks which is healthier, which has more protein, or any cross-food comparison') and why it's better (cheaper and clearer than alternatives). It also names the alternative tool nutrition_detail.

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