Nutrition for 910 plant foods across 11 national datasets, plus GB/EU & US claim checking
Scored across 8 tools
Each tool has a clearly distinct job: slug lookup, nutrient profile, nutrient ranking, recipe search, recipe detail, health topics, herb monographs, and claim validation. The search/detail pairs are explicitly separated, so an agent should not confuse them.
Most tools follow a verb_noun pattern like check_claim, get_recipe, lookup_food, search_foods, and search_recipes. A few are noun phrases instead (health_topic, herb_monograph, nutrient_ranking), so the convention is not fully uniform but remains readable and predictable.
Eight tools is well-scoped for a nutrition server. Each tool earns its place and covers a distinct aspect of food lookup, recipe discovery, health guidance, herbs, and claims.
The tool surface forms complete workflows: search_foods leads to lookup_food or herb_monograph, search_recipes leads to get_recipe, and health_topic points to relevant recipes. There are no obvious dead ends or missing core operations for the stated raw-food nutrition domain.
For a RAW or minimally-processed whole food, report which nutrition claims ("source of iron", "high in vitamin C", "high fibre") the published data supports under GB/EU rules (15%/30% of NRV per 100 g, Reg. 1924/2006) and US rules (10-19%/20% of DV per RACC, 21 CFR 101.54) — and, uniquely, flag where that answer DEPENDS ON WHICH national food-composition table was used, since the eleven tables reconciled here disagree on the same food by a median of 1.63x. Applies to claims wherever they appear, including websites and advertising (Reg. 1924/2006 Art. 1(2)), not only packaging. NOT valid for cooked or manufactured products — their composition depends on recipe and processing. Screening only: under Art. 5(1)(b)(i) the nutrient must be in THE FINAL PRODUCT, so a supported claim still needs an analysis of the producer's own produce. Never treat this as a way to pick a source that qualifies.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Food slug or name — e.g. "banana", "brazil-nuts". | |
| market | No | Which rules to apply. Default "both" — the divergence is usually the point. | |
| nutrient | No | Optional: check one nutrient only, e.g. "potassium". | |
| preparation | No | Must be "raw" (the default). This tool holds raw and minimally-processed commodity data only and REFUSES anything else, because cooking changes composition in both directions — vitamin C and folate are destroyed while minerals concentrate as water is lost. If the food you are asking about has been cooked, juiced, or made into a product, do not call this tool: its answer would not describe your product, and a nutrition claim is a legal statement about the product actually sold. | |
| only_permitted | No | Optional: return only claims the data supports, dropping the ones that fail. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and meets it thoroughly: it discloses refusal behavior for non-raw foods, legal scope beyond packaging, screening-only limits, and the requirement that claims ultimately need analysis of the producer's own product. This goes well beyond a typical tool description.
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 dense and every clause earns its place, but it is a single long paragraph with legal citations and multiple caveats. It is front-loaded with the core purpose and is still readable, though it would benefit from clearer structural separation.
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 complex tool with no output schema and no annotations, the description is very complete: it covers scope, exclusions, legal basis, and screening caveats. A small gap is the ambiguity between 'raw or minimally-processed' in the description and the preparation parameter only allowing 'raw'.
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 documents each parameter thoroughly, including the 'raw' restriction and the 'both' default. The description adds legal thresholds and table-divergence context, but not additional parameter-level meaning beyond what the schema already provides.
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 uses a specific verb-resource pair: 'report which nutrition claims ... the published data supports under GB/EU rules ... and US rules'. It also states its unique differentiator — flagging dependence on which national food-composition table was used — which separates it from generic nutrient lookup tools.
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 explicitly states when to use the tool ('For a RAW or minimally-processed whole food') and when not to ('NOT valid for cooked or manufactured products', 'do not call this tool'). It also warns it is screening-only and must not be used to pick a qualifying source, but it does not name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Heathy recipe in full: ingredients with their food slugs and gram weights, method, per-serving nutrition, allergens and carbon footprint. All recipes are original, strictly raw / no-cook and vegan. The nutrition is computed from the ingredient food rows rather than entered by hand, so each figure traces back to the national datasets lookup_food cites. Accepts a slug or the recipe name; use search_recipes to find one.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | Recipe slug or name — e.g. "dragon-fruit-coconut-breakfast-bowl". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful context: recipes are original, strictly raw/no-cook, and vegan, and nutrition figures are computed from ingredient food rows rather than entered by hand. It stops short of describing response structure or error behavior, but the provenance and content constraints are genuinely useful.
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 four sentences and wastes little space: it front-loads the purpose, then adds constraints, provenance, and usage guidance. Each sentence earns its place, though the typo 'Heathy' is a minor blemish.
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?
Given that there is no output schema, the description compensates by enumerating the returned recipe components and clarifying the accepted input format plus the search_recipes alternative. It could mention invalid-slug or error behavior, but it is sufficient for an agent to select and invoke the tool 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?
The input schema already fully describes the single parameter as 'Recipe slug or name' with an example, giving 100% schema coverage. The description's phrase 'Accepts a slug or the recipe name' adds no new semantic information beyond what the schema provides, so the baseline of 3 is appropriate.
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 opens with a specific action and target — 'Get one Heathy recipe in full' — and enumerates exactly what that includes: ingredients with slugs and gram weights, method, per-serving nutrition, allergens, and carbon footprint. This clearly distinguishes it from sibling tools like search_recipes, which finds recipes rather than retrieving a full one.
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?
The description states that the tool accepts a slug or recipe name and explicitly directs users to search_recipes when they need to find one. This is a clear routing instruction for the main alternative, though it does not enumerate exclusions for the other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What to eat for a health goal — the nutrients involved, why each one, and which raw recipes carry them. Call this before answering "what should I eat for X". Accepts a goal ("gut health", "bone-health") or a named condition ("PCOS", "ADHD", "anaemia"): condition names resolve even though topic titles are physiological. Crucially, topics that people reach for with a diagnosis carry an explicit note saying what the evidence does and does NOT support, at its own rating — for ADHD and autism that note says diet is not a treatment, per NICE. Reproduce those notes rather than summarising them away. Omit the argument to list every topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Goal slug or title, or a condition name — e.g. "digestion-gut", "PCOS", "anaemia". Omit to list all topics. | |
| include_recipes | No | Include raw recipes carrying this goal. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses that condition names resolve even when titles are physiological, that diagnosis-related topics include evidence notes with their own rating, and that for ADHD and autism the note explicitly says diet is not a treatment per NICE. It also instructs the agent to reproduce those notes rather than summarize them away, which is a critical behavioral directive.
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 dense but every sentence earns its place: purpose, usage trigger, parameter semantics, evidence-note behavior, reproduction instruction, and the omit-argument case. It is front-loaded with the core purpose and remains readable despite covering a lot of nuance.
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 tool with no output schema and no annotations, this description is remarkably complete. It covers what the return content is, how to handle condition-related evidence notes, how arguments affect behavior, and what happens when the argument is omitted. An agent has enough information to invoke the tool correctly and use its output appropriately.
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?
The schema already provides 100% parameter coverage, giving the baseline of 3. The description adds meaningful extra semantics for the 'topic' parameter by explaining that it accepts goals or condition names and that condition names resolve correctly. The 'include_recipes' parameter is not elaborated in the description, but the schema already explains its default and meaning.
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 exactly what the tool provides: what to eat for a health goal, the nutrients involved, why each one matters, and raw recipes that carry them. It also gives a clear invocation trigger, 'Call this before answering "what should I eat for X"', which distinguishes it from recipe-searching and nutrient-ranking siblings. The scope is unambiguous even without naming alternatives 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 explicitly tells the agent when to call the tool before answering 'what should I eat for X', and it clarifies that condition names as well as goal names are accepted. It does not explicitly state when not to use it or mention sibling alternatives, but the context is clear enough for correct selection in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a sourced monograph for an Ayurvedic herb, with traditional use and modern research kept strictly separate and never blended: traditional records what the tradition claims, modern records what research shows with an evidence tier (1 = strongest). Every response includes a mandatory safety block — cautions, pregnancy guidance and drug interactions — which must be reproduced alongside any information taken from this tool. Accepts English, Sanskrit, Hindi or botanical names ("turmeric", "haldi", "Curcuma longa").
| Name | Required | Description | Default |
|---|---|---|---|
| herb | Yes | Herb slug or name — English, Sanskrit, Hindi, or botanical. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals important behavioral traits: traditional and modern claims are kept strictly separate, an evidence tier accompanies modern research, a mandatory safety block is always present, and the safety block must be reproduced alongside any tool output. This is rich, non-obvious behavioral guidance that an agent needs to use the tool correctly.
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 deliver purpose, output structure, safety requirements, and accepted input forms with zero filler. The most important information is front-loaded, and each sentence earns its place. The length is justified by the tool's non-obvious output contract.
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 and no annotations, the description must explain return structure and usage constraints on its own. It covers the traditional/modern split, the evidence tier scale, the mandatory safety block, and the reproduction requirement. This is sufficient for an agent to call the tool and correctly interpret and propagate its results.
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?
The input schema already describes the herb parameter as 'English, Sanskrit, Hindi, or botanical,' so baseline schema coverage is high. The description adds value by providing concrete examples ('turmeric', 'haldi', 'Curcuma longa') and emphasizing the accepted name forms in a user-facing sentence, making it easier for an agent to pick a valid value. It does not introduce new parameters or contradict 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?
The description opens with a specific verb and resource: 'Get a sourced monograph for an Ayurvedic herb'. It clearly differentiates the tool from siblings like get_recipe, lookup_food, or health_topic, and further clarifies the output's internal structure (traditional vs modern). An agent can immediately understand what this tool does and what it returns.
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?
The description provides clear context for when to use the tool: whenever a sourced Ayurvedic herb monograph is needed. It also specifies accepted name forms (English, Sanskrit, Hindi, botanical), which helps the agent choose valid inputs. However, it does not explicitly state when not to use it or name alternative tools for overlapping needs, such as health_topic or check_claim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full per-100 g nutrient profile of a whole plant food, reconciled across up to 11 national food-composition datasets (USDA, UK CoFID, IFCT India, Ciqual, BLS, Frida, and more). Unlike a single-source table, every value reports how many sources contributed, which ones, and the per-source spread — so the number can be cited rather than asserted. Covers Indian foods from IFCT 2017, which is not available as an API elsewhere. Accepts a slug ("bitter-gourd") or a plain or regional name ("karela", "chickoo").
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Food slug, common name, or regional alias. | |
| nutrients | No | Optional nutrient slugs or names to return (e.g. ["iron","vitamin-c"]). Omit for the full profile of ~168 nutrients. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It adds valuable behavioral context: every nutrient value reports how many sources contributed, which ones, and the per-source spread, and the data is reconciled rather than asserted. It could mention not-found handling, but the key non-obvious traits are disclosed.
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 with no waste: the first states what the tool returns, the second explains why the data is more trustworthy than single-source alternatives, and the third describes acceptable inputs. Every sentence earns its place and the key information is front-loaded.
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?
The tool is a simple read-only lookup with one required string and an optional filter, and the description covers input formats, data provenance, and the useful IFCT 2017 coverage edge case. Since there is no output schema, the description sufficiently predicts the return content. A minor gap is explicit guidance for handling unknown foods.
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 concrete input examples for the food parameter ('bitter-gourd', 'karela', 'chickoo') and explains that the optional nutrients parameter filters the result. This goes beyond the schema's generic type descriptions.
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 leads with a specific verb and resource: 'Get the full per-100 g nutrient profile of a whole plant food.' It also distinguishes itself from sibling lookup tools by emphasizing multi-source reconciliation across up to 11 national datasets, which is a unique, clearly stated capability.
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?
The description explains acceptable input forms ('slug, common name, or regional alias') and highlights a unique coverage area (Indian foods from IFCT 2017). It does not explicitly say when to use a sibling tool like search_foods instead, but the context is clear enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank whole plant foods by how much of a nutrient they provide per 100 g — the "highest in vitamin C / iron / calcium" question, answered from reconciled multi-source data rather than one national table. Optionally filter by food category. Each result reports how many sources backed the value, so thinly-sourced outliers can be spotted or excluded via min_sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1–100. Default 20. | |
| category | No | Optional substring filter on the food category — e.g. "fruit", "legume", "millet". | |
| nutrient | Yes | Nutrient slug or name — e.g. "iron", "vitamin-c", "folate". | |
| min_sources | No | Only include values backed by at least this many datasets (1–11). Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses normalization per 100 g, multi-source reconciliation, per-result source counts, and the ability to exclude thinly sourced outliers via min_sources. This is meaningful behavioral context beyond what the schema alone would reveal.
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 three sentences with the core ranking behavior front-loaded, followed by filtering and data-quality caveats. Every sentence earns its place and no schema details are redundantly repeated.
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 moderate-complexity tool with no output schema, the description covers the essential call semantics: what is ranked, in what unit, over what food scope, how optional filters work, and what the result's source-count field means. An agent has enough information to invoke it correctly and interpret its output.
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; the description enriches this by explaining 'per 100 g' as the ranking basis, giving concrete examples for nutrient and category, and clarifying min_sources as a mechanism for spotting or excluding weakly supported values. This adds real meaning beyond the parameter descriptions.
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 opens with a precise verb and resource: 'Rank whole plant foods by how much of a nutrient they provide per 100 g,' which fully states the operation and scope. It also frames the exact question the tool answers ('highest in vitamin C / iron / calcium') and distinguishes it from singleton food lookups by highlighting reconciled multi-source data.
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?
The description clearly conveys when to use the tool: when the user wants a per-100g ranking of plant foods by a nutrient, optionally filtered by category. It does not explicitly name sibling alternatives or exclusion conditions, but the 'highest in...' framing and plant-food scope provide enough guidance for an agent to select it over search/lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the Heathy slug for a food or Ayurvedic herb by name, including regional and non-English aliases (Hindi, Sanskrit, botanical names). Call this first when you have a plain-English or local name and need the slug for lookup_food or herb_monograph. Returns ranked candidates rather than guessing a single answer.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to foods or Ayurvedic herbs. Default "any". | |
| limit | No | Max results, 1–50. Default 10. | |
| query | Yes | Name, partial name, or alias — e.g. "haldi", "bitter gou". |
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 usefully discloses that the tool returns ranked candidates rather than a single guess, and that it handles aliases. However, it does not describe the output format, limit behavior, or any edge cases, and since there is no output schema, more behavioral detail would be valuable.
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, no wasted words. The core purpose is front-loaded, usage context is in the second sentence, and behavioral nuance is in the third. Every sentence contributes meaning.
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 simple search tool with three well-documented parameters, the description covers purpose, when to use it, and key behavioral expectations. The absence of an output schema is partially mitigated by the statement that it returns ranked candidates, but a bit more detail about the result fields would fully complete the picture.
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?
The input schema has 100% description coverage for all three parameters, including examples like 'haldi' and 'bitter gou.' The description doesn't need to repeat parameter details; it adds mild context by explaining that aliases are searched, but most of the semantic weight is already in the schema. Baseline 3 is appropriate.
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: 'Find the Heathy slug for a food or Ayurvedic herb by name.' It also distinguishes itself from siblings by explicitly referencing lookup_food and herb_monograph as downstream consumers of the slug. The mention of regional, Hindi, Sanskrit, and botanical aliases adds clarity beyond the tool name.
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?
The description gives explicit guidance: 'Call this first when you have a plain-English or local name and need the slug for lookup_food or herb_monograph.' This clearly tells an agent when to use the tool. It does not explicitly name alternative tools or state when not to use it, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find raw / no-cook vegan recipes on Heathy by free text, health goal, category, ingredient, time or allergen. Every recipe is original and its per-serving nutrition is computed from the same food rows lookup_food returns, so figures are checkable rather than asserted. Returns ranked summaries — call get_recipe with a slug for ingredients, method and full nutrition. For "what should I eat for X" questions, prefer health_topic first: it says what the evidence actually supports for a goal or a named condition.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Restrict to recipes carrying this health goal. | |
| limit | No | Max results, 1–50. Default 10. | |
| query | No | Free text over name, description and tags — e.g. "dragon fruit", "breakfast". | |
| category | No | Restrict to one recipe category. | |
| max_time | No | Maximum total time in minutes. | |
| ingredient | No | Food slug or name that must appear in the ingredients — e.g. "pitaya-raw". | |
| exclude_allergens | No | Drop recipes containing any of these allergens — e.g. ["tree-nuts","sesame"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers important behavior: it returns ranked summaries, recipes are original, and nutrition figures are computed from the same food rows as lookup_food, making them checkable. It does not explain ranking behavior or query semantics, but it gives a clear behavioral picture 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose and search dimensions, data provenance, output type with a pointer to get_recipe, and a routing note for health_topic. The most important operational detail, that this returns summaries, is clearly stated before the alternative is mentioned.
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?
Despite having no output schema, the description tells the agent what to expect (ranked summaries), where to go for full recipe details (get_recipe), and when to use a different tool (health_topic). For a 7-optional-parameter search tool, this is sufficient for both selection and invocation.
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 description coverage is 100%, so the parameter documentation is already complete. The description adds only conceptual mapping by listing search dimensions (free text, health goal, category, ingredient, time, allergen) which mirror the schema fields but add no new semantic detail beyond what the schema provides.
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 opens with a specific verb ('Find') and names the exact resource: raw / no-cook vegan recipes on Heathy, searchable by multiple criteria. It also distinguishes itself from get_recipe by clarifying that this tool returns ranked summaries rather than full recipe details.
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?
The description gives explicit routing guidance: use get_recipe for ingredients, method and full nutrition, and prefer health_topic for 'what should I eat for X' questions. This tells an agent exactly when this tool is the right choice and when to use a sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_claimget_recipehealth_topicherb_monographlookup_foodnutrient_rankingsearch_foodssearch_recipesFood and nutrition data: search, macros, and comparisons
USDA FoodData Central nutrient lookup, FDA recall watch, EU FMCG labelling via remote MCP
Food photo recognition, nutrition search, meal logging and glucose prediction for health apps
Evidence-based plant-based food-as-medicine protocols for 47 chronic conditions. ACLM-aligned.
Add one secure layer between your agents and this server.