Server Quality Checklist

Tool Scores

• cooking_tipsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It transparently lists the covered dietary goals, but does not disclose whether tips are generic/personalized, whether they include warnings, or whether the tool returns a static list. The content scope is clear, but behavioral details are minimal.

  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, front-loaded sentence that immediately conveys the tool's purpose and scope with zero filler. It earns its place entirely.

  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's simplicity (one optional parameter, high schema coverage, and an output schema), the description is sufficient to inform basic usage. It could be slightly richer by mentioning the 'all' default or return style, but it is not incomplete for practical invocation.

  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 `goal` parameter, so the schema already provides the parameter's meaning. The description repeats the goal categories but adds no extra semantic detail (e.g., format, defaults, or examples), fitting the baseline for high 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 clearly identifies the tool's scope: practical kitchen techniques for removing potassium/phosphorus, controlling sodium, and supplementing calories. It distinguishes this from sibling tools by focusing on cooking methods rather than food eligibility, substitution, or lab interpretation, though it lacks an explicit verb.

  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 offers no explicit guidance on when to use this tool versus alternatives. There are no references to sibling tools or any 'when-to-use/not-use' statements, leaving the agent to infer usage from the name and context.

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

• search_faqA
  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 says 'search' and gives examples, but does not disclose whether it returns full Q&A pairs, how matching works, or that it is a read-only operation. No additional behavioral context is provided beyond the raw action.

  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 that efficiently conveys the purpose with relevant examples. There is no redundant or filler content; it is appropriately front-loaded and concise.

  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 schema fully documents parameters and an output schema exists, so return handling is covered. However, the description lacks usage guidance and behavioral expectations, which leaves some gaps for a search tool with multiple siblings. It is adequate but not fully 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 description coverage is 100%, meaning both parameters (question and limit) are already documented in the schema. The tool description adds no extra parameter-level meaning, so the baseline score 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 verb '检索' (search) and specifies the resource '家长高频问题库' (parents' high-frequency question bank), with clarifying examples like low-salt diet and hormone side effects. This clearly differentiates it from sibling tools such as search_food and list_faq_topics.

  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 looking up common parental questions but does not explicitly state when to use this tool over siblings like list_faq_topics or explain_terms. There are no explicit exclusions or alternative tool names, leaving the when-to-use conditions to be inferred.

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

• explain_termsA
  3.6/5.0
  Behavior3/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 explains the basic transformation (translating terms to plain language), but does not disclose any limitations, edge cases, or output specifics. Since this is a simple, non-mutating text tool, the lack of extra context is not severe, but it is still only minimally sufficient.

  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 leads with the action ('把…翻译成大白话'), with no redundant words. It is appropriately concise and structurally clear.

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

  Completeness4/5

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

  The tool is simple with two parameters and an output schema, and the description adequately captures its core purpose. However, it lacks explicit usage guidance and sibling differentiation, which prevents a higher score given the existence of related tools like 'translate_doctor_note'.

  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 both parameters, so the baseline is 3. The description adds small context by specifying text types ('医嘱、诊断、检查报告') and implying '逐个' (one-by-one) behavior, but this does not significantly go beyond what the schema already states.

  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 ('翻译' / translate) and resource ('医学文字里的专业术语' / professional terms in medical text), clearly stating that terms are explained one by one in plain language. This makes the function clear, but it does not explicitly distinguish itself from sibling tool 'translate_doctor_note', though the term-level focus implicitly differentiates.

  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 a user wants plain-language explanations of medical terms, but it offers no explicit when-to-use/when-not-to-use guidance nor mentions alternatives among sibling tools. This is implied usage rather than clear context.

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

• egfr_calculatorA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses the formula used (bedside Schwartz) and the special rule for children under 2 (not applying G1–G5), which are valuable behavioral traits. However, it does not mention error handling, unit handling (e.g., both creatinine units provided), or prerequisites 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?

  The description is a single, well-structured sentence that is front-loaded with the core purpose and immediately states the key exception. No wasted words or redundant information.

  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?

  An output schema exists, so return values are covered separately. The description adequately conveys the calculation method and an important clinical caveat. However, it lacks guidance on when to use this tool versus related tools, making it slightly less complete for an agent deciding among siblings.

  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 baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only mentions the formula and age rule. The schema already documents each parameter with units and required status, so the description adds marginal value here.

  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 action: calculate eGFR using the bedside Schwartz formula and determine CKD stage, with an explicit exception for children under 2 years. This distinguishes it from siblings like ckd_stage_overview, which likely provides general staging context rather than calculation.

  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?

  Usage context is implied by the function name and description, but there is no explicit guidance on when to use this tool versus alternatives like interpret_lab_report. No exclusions or alternative recommendations are provided, leaving the agent to infer suitability.

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

• translate_doctor_noteA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It states the two outputs (translation and question list) but does not disclose limitations such as translation accuracy, scope of generated questions, or any prerequisites for the input. This is adequate but not rich.

  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 that immediately states the action and output, with no redundant words. It is appropriately front-loaded and concise.

  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 one-parameter tool with an output schema present, the description fully captures what the tool does and what to expect. No annotations are needed given the low complexity, and the description is complete for selection and invocation.

  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 has a description for the 'text' parameter ('医生诊断或医嘱原文。') that fully covers its meaning. The tool description adds no additional semantic detail beyond that, and schema coverage is 100%, so the baseline 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 specific verbs 'translate' and 'generate' applied to a defined resource (医生写的诊断/医嘱) and names a concrete output (下次复诊该问医生什么清单). It clearly differentiates from sibling tools like explain_terms (individual term explanation) and interpret_lab_report (lab interpretation) by focusing on whole-note translation plus follow-up questions.

  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 clearly implies when to use it: when a user has a full doctor's note and wants a translation plus a list of questions for the next visit. It provides this context clearly but does not explicitly mention alternatives or exclusions, which would warrant a 5.

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

• daily_standardsA
  4.2/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the transparency burden. It discloses two behavioral modes: listing stage-wise standards and producing individualized goals. It doesn't explain calculation details or side effects, but for an informational/reference tool, this is adequate.

  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 sentences, front-loaded with the main function in the first sentence and usage guidance in the second. It is concise with no redundant wording.

  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's complexity (12 params, many optional) and the existence of an output schema, the description covers the primary use cases and output scope well. It doesn't address edge cases or interactions with other tools, but the essential context for when to use it is present.

  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% (every parameter has a description), so the baseline is 3. The tool description adds no parameter-level meaning beyond mentioning that the tool handles nutrients and stages, but it doesn't elaborate on any specific parameter.

  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 provides daily nutritional intake standards for energy, protein, sodium, potassium, phosphorus, calcium, and fluid for the child. It uses a specific verb ('给出' / provide) and a defined resource, and it distinguishes itself from sibling tools like can_eat by explaining when it should be used (e.g., when stage is unknown).

  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 gives two usage scenarios: when a parent asks 'can XX eat' without a CKD stage, call this tool to list standards for each stage for comparison; after confirming stage, use it to give individualized goals. It does not mention alternative tools by name, but the contextual triggers are clear.

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

• interpret_lab_reportA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses key behaviors: item-by-item translation, reliance on specific guidelines (KDIGO, KDOQI, etc.), handling of discrepancies by listing options and deferring to local reference values, and output of red_flags and next_actions. This is substantive, though it could also mention how missing inputs are handled.

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

  Conciseness5/5

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

  The description is three concise sentences. The first sentence immediately captures the trigger and action. The second and third add valuable context about evidence sources, handling of disagreements, and output features without redundancy or filler. Every sentence earns its place.

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

  Completeness4/5

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

  The tool has 21 parameters (all schema-described) and an output schema, so parameter and return details are covered elsewhere. The description fills in the purpose, use case, evidence basis, and behavior (red_flags/next_actions). It could be slightly more explicit about expected input combinations (e.g., which labs are needed), but overall it is complete enough for effective selection and invocation.

  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% description coverage, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema; it only explains the overall purpose. The schema already documents each parameter's units and significance, so no deduction is warranted.

  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 ('translate') and resource ('lab report'), with a concrete trigger scenario ('when parents ask how to read it'). It distinguishes itself from sibling tools like translate_doctor_note (which handles notes) and explain_terms (which likely explains individual terms) by focusing on interpreting lab report items into plain language for parents.

  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 says when to use ('when parents ask how to read the lab report'), which is clear context. However, it does not explicitly mention when not to use it or point to alternative tools (e.g., explain_terms for single terms), so it falls short of the highest bar.

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

• list_faq_topicsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It adds a return format (id, category, question), which is useful. However, it does not clarify that the operation is read-only, possible absence of authentication, or any pagination/sorting behavior. For a simple list tool, this is adequate but not rich.

  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 one sentence plus a brief returns line. It is front-loaded with the main purpose and contains no redundant information. Every word contributes value, making it concise and well-structured.

  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 low complexity (no parameters, simple list operation) and the existence of an output schema, the description provides enough context: it states the purpose and the expected shape of the return. It does not need to elaborate further, as the output schema covers the detailed return structure.

  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 is empty. Per the guidelines, the baseline is 4 for 0 params. The description does not need to explain parameters, but it also does not explicitly confirm 'no parameters' to the user, so it does not earn a 5.

  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: listing all topics of the parents' FAQ bank. The verb '列出' (list) and resource '全部主题' (all topics) are specific, and the purpose '便于引导家长提问' adds context. This distinguishes it from siblings like search_faq, which searches rather than lists.

  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 implies a clear use case: when you need to guide parents by showing available FAQ topics. It does not explicitly mention alternatives or exclusions, but the purpose provides enough context to know when to use it. Since no sibling is mentioned, it stops short of a 5.

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

• ckd_stage_overviewA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the intended audience (parent version), the trigger scenario, and the return structure (each entry contains stage, focus, potassium, phosphorus, protein, sodium). This gives sufficient context for a safe read-only list operation, though it does not explicitly state that it is a static overview.

  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 short and front-loaded. The first sentence states the main purpose, the second provides usage guidance, and the final line lists the output fields. Every word earns its place without fluff or 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 tool's simplicity and existing output schema, the description is complete enough. It explains what it does, when to use it, and what is returned. However, it does not explicitly differentiate itself from sibling tools like daily_standards, which might also provide dietary recommendations, leaving some potential ambiguity.

  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, so the baseline is 4. The description does not need to explain input semantics and instead focuses on what the output will be, which is appropriate for a parameterless lookup tool.

  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: listing all CKD stages' dietary management principles (potassium/phosphorus/protein/sodium) for parents. The verb 'list' and specific resource 'all CKD stages' make it unambiguous, and the audience (parent version) distinguishes it from potentially similar clinical tools.

  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 states when to call: when the parent has not specified the stage and needs to understand that different stages are very different. This provides a clear trigger and implies when not to use it (when the stage is already known), but it does not explicitly name alternatives among siblings.

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

• search_foodA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses the fuzzy search behavior and score-based sorting, and explains the data source. It does not explicitly state read-only behavior, but for a search tool this is implied; the added purpose gives useful context.

  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 sentences: first the action and output, second the purpose. It is concise, front-loaded, and contains no unnecessary 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 search tool with an output schema, the description is complete. It covers the domain, matching behavior, and intended use case. There is no need to explain return values since the output schema exists.

  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 (keyword, limit) with 100% coverage. The description adds value by clarifying that the search is fuzzy by food name and scoped to the food composition table, giving more meaning to the keyword parameter beyond the schema's generic 'food keyword'.

  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 identifies the tool's action (fuzzy search food by name), the specific resource (China Food Composition Table), and the output (candidates sorted by score). It distinguishes itself from sibling tools like find_substitutes or can_eat by focusing on name lookup/verification.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: confirming what a parent's mentioned food is called in the composition table and verifying the correct entry. It does not explicitly mention when not to use the tool or name alternative tools, but the context is sufficient for selection.

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

• find_substitutesA
  4.6/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 the operation is deterministic, involves calculating equivalent amounts, checking electrolyte increments, and automatically filtering red/yellow card foods. It also explains sorting by safety score, which is valuable behavioral context.

  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 and well-structured, front-loading the trigger condition and using a few sentences to convey the algorithm and key behaviors. There is no filler or 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 tool has 12 parameters and an output schema, the description provides a high-level but sufficient overview of purpose, algorithm, and safety filtering. It doesn't explain every parameter, but schema descriptions cover that. It is complete enough for an agent to understand when and how to invoke it.

  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 has 100% description coverage, so the baseline is 3. The description adds context by explaining how parameters relate, such as basis determining protein vs energy equivalence and ckd_stage affecting penalty scoring. This goes slightly beyond individual parameter descriptions.

  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: to find food substitutes when a parent asks what to replace. It uses a specific trigger phrase and describes the core functionality. This distinguishes it from sibling tools like can_eat or search_food.

  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 says when to call: when a parent asks about substituting a missing food item. It provides clear contextual guidance but does not explicitly name alternatives to avoid, though the trigger is specific enough to guide usage.

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

• can_eatA
  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 of behavioral disclosure. It thoroughly explains the tool's behavior: red/yellow card interception, returning need_more_info for incomplete input, reverse-calculating portion limits from daily budgets, providing green/yellow/red light conclusions, and applying amount_g restrictions. This goes beyond a basic summary and gives the agent a clear mental model of the tool's process.

  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 dense but every clause earns its place. It front-loads the trigger condition, then logically proceeds through interception, missing-info handling, complete-information calculation, and amount_g-specific guidance. No filler words, and the structure mirrors the tool's execution flow.

  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 13 parameters, an output schema, and complex decision rules, the description gives a complete overview: it covers the rule-based interception, the need_more_info branch, the calculation methodology (potassium/phosphorus/sodium/protein budgets), the output conclusion format (traffic light), and the handling of optional amount_g. This is enough for an agent to invoke the tool correctly even in edge cases.

  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?

  Although schema coverage is 100%, the description adds significant meaning beyond the field descriptions. It explains that ckd_stage, age_years, and weight_kg are triggers for need_more_info if missing, and that amount_g is used to provide a limit reminder. This connects the parameters to the tool's decision logic, which 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 a specific trigger condition ('家长问「XX 能不能吃」时调用') and clearly states the tool's function: to evaluate whether a food is safe for a CKD patient, using red/yellow card rules, nutritional budgets, and portion calculations. This distinguishes it from sibling tools like find_substitutes or cooking_tips, which have different purposes.

  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 says when to call (when a parent asks if a food can be eaten) and provides context for handling missing information (asking for CKD stage/age/weight). However, it does not explicitly mention when not to use the tool or name alternative sibling tools, so it lacks the full when/when-not/alternatives guidance.

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