nutrition

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial behavior: it REFUSES non-raw input, warns that the 30 reconciled tables disagree by a median of 1.96x, and states it does not select a qualifying table. It does not describe pagination or latency, but for a screening tool this is strong disclosure.

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

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

Front-loaded with scope and the NOT-valid exclusion, with a clear screening-only qualifier at the end. It is long, and the raw/preparation reasoning partly restates the schema's own parameter description, so a few sentences do not fully earn their place.

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

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

No output schema exists, so the description must carry the return contract, and it does: results list the tables that do and do not support each claim and the tool does not pick a qualifying table. Combined with the scope and refusal rules, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the schema already documents every parameter in detail. The description adds genuine meaning on top: the market default is justified ("the divergence is usually the point"), which tells the agent why 'both' matters rather than just what it does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (report which nutrition claims the published data supports) and immediately scopes it to GB/EU and US rules with concrete thresholds. It is unmistakably distinct from every sibling (lookup_food, nutrient_ranking, search_foods), none of which evaluate legal claim thresholds.

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

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

It gives explicit when-to-use (raw or minimally-processed whole food, unfortified single-ingredient flour) and when-not (cooked, juiced, or manufactured products), and instructs the agent not to call it in those cases. The screening-only caveat under Art. 5(1)(b)(i) further bounds what the result means.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds value beyond annotations by disclosing that recipes are original and strictly raw/no-cook/vegan, and that nutrition is computed from ingredient food rows traced back to national datasets cited by lookup_food. This gives useful context about data provenance and content characteristics. No contradictions found.

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

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

The description is a single focused paragraph that front-loads the core purpose ('Get one Heathy recipe in full') and then adds supporting details about contents, recipe origin, nutrition computation, and how to find a recipe. Every sentence contributes information, though it is slightly dense; it could be trimmed without losing value.

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

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

Since there is no output schema, the description explicitly lists the return contents (ingredients, method, per-serving nutrition, allergens, carbon footprint), which is the critical information for an agent. It also explains nutrition provenance. It does not mention error behavior or not-found handling, but for a read-only, idempotent single-item get tool, that is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already describes the single 'recipe' parameter as a slug or name with an example. The description largely restates this ('Accepts a slug or the recipe name') and points to search_recipes for discovery, but it doesn't add new format details or semantics beyond what the schema provides. Baseline 3 is appropriate when the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get one Heathy recipe in full') and enumerates the contents (ingredients with food slugs and gram weights, method, per-serving nutrition, allergens, carbon footprint). It also distinguishes itself from search_recipes by explicitly noting it accepts a slug or name, showing the agent which tool to use for retrieval vs discovery.

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

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

Explicitly directs the agent to use search_recipes when it needs to find a recipe ('use search_recipes to find one'), creating a clear when-to-use vs when-not-to-use boundary. It also describes the recipe characteristics (original, raw/no-cook, vegan) so the agent can decide if this tool satisfies the query.

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

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

Annotations already declare a safe read (readOnly, idempotent, non-destructive), so the description is free to add domain behavior — condition names resolving despite physiological titles, the presence of evidence notes with their own rating, and the NICE-based caveat that diet is not a treatment for ADHD/autism. That is meaningful behavior beyond the annotations; only return/pagination detail is absent.

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

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

The purpose and the accepted argument forms are front-loaded, and each sentence carries distinct information about inputs and evidence behavior. It is fairly dense in the middle, but no sentence is redundant filler.

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

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

For a read-only lookup with full annotation coverage and no output schema, the description supplies enough: what it returns conceptually (nutrients, reasons, recipes), input resolution rules, and the caveat content. Return format detail is omitted, but that is a minor gap given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: condition names ("PCOS", "anaemia") resolve even though topic titles are physiological, and omitting the argument lists everything. This clarifies the topic parameter's accepted forms beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (goal-oriented nutrition topics) and scope (nutrients, rationale, raw recipes), and frames the exact question it answers ("what should I eat for X"). It clearly distinguishes itself from narrow siblings like lookup_food or nutrient_ranking by covering the goal-level synthesis, though it never names a sibling explicitly.

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

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

It tells the agent the trigger question ("what should I eat for X") and the argument forms that work (goal vs. named condition), plus the no-argument behavior. It gives clear context but no explicit exclusions or direct routing to alternatives such as search_recipes or nutrient_ranking.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-annotation detail: traditional and modern content are 'never blended', evidence tiers are ranked (1 = strongest), and each response carries attribution, disclaimer, source_url and a safety block with cautions, pregnancy guidance and drug interactions.

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

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

The core action is front-loaded in the first clause and every subsequent clause carries real information (separation rule, tier semantics, return fields, accepted inputs). It is dense and slightly run-on, but nothing is padding.

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

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

With no output schema, the description fully compensates by enumerating the returned blocks and their contents, and the annotations already carry the read/idempotency profile. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already lists the four accepted name languages, so the baseline is 3; the description earns an extra point by giving concrete interchangeable examples ('turmeric', 'haldi', 'Curcuma longa') that make the lookup key's flexibility unambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get a sourced monograph for an Ayurvedic herb') and immediately differentiates the payload structure (traditional vs modern, evidence tier, safety block) in a way that separates it from siblings like check_claim, health_topic or lookup_food.

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

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

Usage is implied by the resource ('Ayurvedic herb') and the accepted name forms are given, but there is no explicit when-to-use/when-not statement and no sibling is named as an alternative (e.g. check_claim for verifying a specific assertion). Adequate but leaves routing to inference.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description goes well beyond them by disclosing the data provenance model — up to 30 tables, per-source contribution counts, and per-source spread — which tells the agent the values are citable and not asserted, plus the 132-nutrient plus 66 research-tier breadth.

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

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

Three sentences, front-loaded with the core capability, then the differentiator, then accepted input formats — efficient and well ordered. Minor redundancy: 'Covers Indian foods from IFCT 2017 (ICMR–NIN, India)' restates IFCT India already named in the source list.

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

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

With only two parameters, no output schema, and rich annotations, the description is nearly sufficient: it explains what comes back (full nutrient profile with source attribution) and what inputs work. It omits behavior for ambiguous names and whether a partial-match returns one record or several, which would matter for a lookup tool without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies. The description adds real meaning beyond the schema's terse 'Food slug, common name, or regional alias' by giving concrete alias examples ('karela', 'chickoo') and the slug form ('bitter-gourd'), which clarifies the fuzzy-match behavior the agent should expect. The optional nutrients filter is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get the full per-100 g nutrient profile of a whole plant food,' with the distinguishing trait of multi-source reconciliation. It contrasts itself with 'a single-source table' rather than naming sibling tools like search_foods, so the differentiation is topical rather than tool-directed.

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

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

Usage is implied (look up a food you can name to get its nutrient profile) but there is no explicit when-to-use versus search_foods, no note on what to do if the name is ambiguous, and no stated exclusions. The accepted-input sentence is helpful context but not routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false, so the safety profile is covered. The description adds genuinely new behavioral context: it returns ranked candidates rather than guessing a single answer, which tells the agent to expect a disambiguation list. No auth, rate limit, or tie-breaking detail beyond that.

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

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

Three tight sentences, front-loaded with the action, followed by the routing purpose and the return-shape caveat. Every sentence earns its place with no restatement of the title.

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

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

No output schema exists, but the description characterizes the return as ranked candidates, which is the key thing an agent needs. Combined with the 100%-covered input schema and read-only annotations, only minor gaps remain (e.g., no hint on how to pick among candidates).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so query, kind, and limit are already documented with examples and defaults. The description reinforces alias coverage (Hindi, Sanskrit, botanical names) but does not add syntax or semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (find/resolve) and resource (Heathy slug for a food or Ayurvedic herb), and explicitly contrasts with lookup_food and herb_monograph, which consume the slug rather than produce it. An agent can distinguish this from its siblings without opening a schema.

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

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

Clearly frames the use case: resolving a plain-English or local name to the slug that lookup_food and herb_monograph accept. The alternative consumers are named, but there is no explicit when-not-to-use guidance (e.g., versus nutrient_ranking or search_recipes) beyond the slug-resolution framing.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds meaningful context beyond that: results are ranked summaries, nutrition is computed from the same food rows lookup_food returns (checkable rather than asserted), and recipes are original.

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

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

Front-loaded with the core purpose and the routing instruction in the second sentence. The trailing sentence about health_topic is tangential to this tool and slightly dilutes focus, but the whole is still compact and readable.

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

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

With no output schema, the description carries the return-value burden and does explain that results are ranked summaries with a follow-up path. It omits any mention of result-count behavior or pagination beyond the limit parameter, which is a minor gap for a 7-parameter search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every filter is already documented, so the baseline is 3. The description enumerates the same dimensions (free text, health goal, category, ingredient, time, allergen) without adding syntax or format detail; the health_topic remark is about a sibling tool rather than clarifying a parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Find) and resource (raw/no-cook vegan recipes on Heathy) plus the filter dimensions, and implicitly distinguishes itself from get_recipe by positioning itself as the summary-level search. An agent can tell it apart from search_foods and nutrient_ranking from the wording.

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

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

Explicitly routes the agent to get_recipe with a slug for full detail, which is clear context for when this tool is sufficient vs. when a follow-up is needed. It does not state when to prefer it over sibling search tools like search_foods, so it stops short of full alternative coverage.

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