Calories and nutrition tables (EU 1169/2011) for recipes, restaurant menus and labels, per portion.
Scored across 2 tools
The two tools have clearly separate roles: calculate_nutrition computes a full nutrition declaration from an ingredient list, while search_foods is a plain database lookup. The descriptions even cross-reference each other, explaining that search_foods is the fallback when an ingredient matches several foods or none, so an agent cannot reasonably confuse them.
Both names follow the same snake_case verb_noun pattern (calculate_nutrition, search_foods) and the verbs accurately predict behavior. No casing or convention mixing.
The server has a deliberately narrow scope, and both tools earn their place: one computes, one resolves ambiguous or missing foods. Two tools is on the thin side but is defensible for a single-purpose calculator; a third lightweight retrieval tool would make the surface feel more complete.
The stated domain (ingredient-list nutrition calculation plus Romanian/European food lookup) is well covered, including per-100g, per-portion, label rounding, menu declaration, and allergen surfacing. There is a gap around retrieving a known food directly by food_id (search is name-based only), and barcode/brand lookup is explicitly out of scope but still a plausible dead end for agents.
Use this when the user wants calories, macros or a nutrition table or label for a recipe or dish from its ingredients (Romanian: valori nutriționale, declarație nutrițională, calorii, la 100 g, per porție). Computes an EU Regulation 1169/2011-style nutrition declaration (energy kJ/kcal, fat, saturates, carbohydrate, sugars, protein, salt) per 100 g and per portion for a recipe, using the Nutrimeniu food database (Romanian and European foods, names in English or Romanian). Each ingredient is a name or food_id with its weight in grams, raw or cooked to match the food. When an ingredient matches several foods or none, the result has no totals and lists the candidate foods, if any, for that ingredient. A complete result also carries the allergens tagged on the matched foods, with a note that tags can be incomplete, an ingredient list sorted by weight with allergens in bold, the five values per portion that Romanian Order ANPC 201/2022 requires on menus (menu_declaration), values rounded for labels (label_rounded), the data source of each ingredient and a disclaimer. purpose is menu for a restaurant menu and label for a product label. Not for packaged products looked up by barcode or brand, for a daily food diary or diet plan, or for the user's own Nutrimeniu recipes. The values are estimates calculated from ingredient data, not laboratory analysis. Completed calculations are limited per conversation. Incomplete results are not counted toward that limit; they share a budget of 50 food lookups per conversation with food searches.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for food names and table labels: en or ro. Default en. | |
| purpose | No | menu: a restaurant menu (Order ANPC 201/2022), shows the five mandatory values per portion first; label: a product label, uses label rounding. Default general. | |
| servings | No | Number of portions the recipe makes. Default 1. | |
| ingredients | Yes | The recipe ingredients, 1 to 30, each with a name or food_id and its weight in grams. | |
| recipe_name | No | Name of the dish, e.g. "Ciorbă de perișoare". Used as the recipe name when the user saves it in Nutrimeniu. | |
| cooked_weight_grams | No | Final weight of the dish after cooking, in grams, when it differs from the sum of the raw ingredients. |
| Name | Required | Description |
|---|---|---|
| format | No | |
| sources | No | |
| complete | No | False when an ingredient is ambiguous or unknown: then there are no totals yet. |
| per_100g | No | |
| allergens | No | Allergens tagged on the matched foods. Tags can be missing: the note says so and unchecked_ingredients lists the foods whose allergen data is not checked. |
| unmatched | No | |
| disclaimer | No | |
| ingredients | No | |
| per_portion | No | |
| save_recipe | No | Present on a complete result: a link that opens this recipe in Nutrimeniu, to keep it as a draft. |
| label_rounded | No | The declaration rounded per the European Commission guidance (December 2012), as strings such as "<0.5". |
| limit_reached | No | Present only when a limit was reached: no search or calculation was made. message explains the limit; register_url, when present, opens the Nutrimeniu sign-up page. |
| ingredients_text | No | Ingredient list sorted by weight, per portion, with allergens in bold (text uses **, html uses <b>). |
| menu_declaration | No | Energy, fat, saturates, sugars and salt per portion, rounded for a menu, with the portion weight (Order ANPC 201/2022). |
| total_weight_grams | No | |
| portion_weight_grams | No | |
| free_calculations_left | No | Free completed calculations left in this conversation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds genuinely new behavior: unresolvable or ambiguous ingredients produce a result with no totals plus candidate foods, allergens come with a caveat that tags may be incomplete, values are estimates rather than lab analysis, and there are per-conversation limits with a shared 50-lookup budget that incomplete results do not consume. These are rate-limit and failure-mode disclosures not derivable from any structured field.
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 trigger sentence and organized from what it produces, to input shape, to failure behavior, to exclusions, to limits, with no filler. It is dense and long (a single paragraph enumerating outputs and caveats), which costs a bit of scanability, but nearly every clause carries decision-relevant information.
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?
An output schema exists so return-value detail is unnecessary, and the description still covers what an agent needs to call correctly: input shape (name/food_id + grams), partial-failure semantics, quota consumption, and disambiguation from neighboring tools. Nothing material is missing for a read-only computation tool of this complexity.
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 earns more by explaining the resolution mechanics behind the ingredient parameters: each ingredient is a name or food_id with grams, raw or cooked to match the food, and the candidate-list behavior explains why food_id exists. It partly restates the schema for purpose/lang, and cooked_weight_grams is left to the schema, so it is not fully additive.
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 ('Computes an EU Regulation 1169/2011-style nutrition declaration ... per 100 g and per portion for a recipe') and explicitly separates itself from adjacent capabilities: barcode/brand product lookup, food diary/diet plan, and the user's own saved Nutrimeniu recipes. It also names the data source (Nutrimeniu food database) and the exact nutrients returned, so an agent can identify the tool without opening the 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?
Opens with an explicit trigger ('Use this when the user wants calories, macros or a nutrition table or label for a recipe or dish from its ingredients'), reinforced with Romanian user phrasings (valori nutriționale, calorii, la 100 g, per porție). It then gives concrete exclusions and routes them elsewhere, which is what a sibling tool like search_foods otherwise leaves ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Nutrimeniu food database (Romanian and European foods, names in English and Romanian, diacritics optional) and return matching foods with their food_id, data source and nutrition values per 100 g (energy kJ/kcal, fat, saturates, carbohydrate, sugars, protein, salt). Use this to look up a food by name, for example an ingredient that matched several foods or none in a nutrition calculation. Searches share a budget of 50 food lookups per conversation with incomplete calculations. Values are estimates from the source data, not laboratory analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the query and of the returned names. Default en. | |
| limit | No | Maximum number of results, 1 to 20. Default 10. | |
| query | Yes | Food name to look for, in English or Romanian (diacritics optional). |
| Name | Required | Description |
|---|---|---|
| foods | Yes | |
| limit_reached | No | Present only when a limit was reached: no search or calculation was made. message explains the limit; register_url, when present, opens the Nutrimeniu sign-up page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety bar is low; the description still adds real behavioral context beyond them: a shared budget of 50 food lookups per conversation, the provenance of values (source data, not laboratory analysis), and diacritics-tolerant matching. These are constraints an agent could not infer from structured fields.
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 and waste-free in intent, with scope, usage and caveat in sequence. The first sentence is long and enumerates every nutrient field even though an output schema exists, which is minor duplication rather than a clarity problem.
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 three-parameter, read-only search with an output schema, the description covers domain, multilingual behavior, budget limits, data provenance and a caveat on estimate quality. Nothing an agent needs to invoke it correctly is missing.
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 query, lang and limit are already documented with ranges and defaults. The description reinforces the cross-language and diacritics behavior of the query parameter but adds no syntax or semantics not present in the schema, so the baseline of 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 and resource (search the Nutrimeniu food database) plus the domain scope (Romanian/European foods, English and Romanian names, diacritics optional) and what is returned (food_id, data source, per-100g nutrition). An agent can distinguish this from calculate_nutrition without opening either 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?
"Use this to look up a food by name, for example an ingredient that matched several foods or none in a nutrition calculation" gives a concrete trigger and implicitly routes the agent here after/around the calculate_nutrition sibling. It lacks an explicit when-not-to-use statement, but the intended invocation context is clear.
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.
calculate_nutritionsearch_foodsFood and nutrition data: search, macros, and comparisons
Nutrition for more than 1,100 plant foods from 30 national tables, plus GB/EU & US claim checking
Recipe nutrition from ingredient lines: USDA FoodData Central values, per serving, FDA rounding.
Calories and nutrition for any food, chain meal or barcode, and meal ideas for a goal and diet.
Add one secure layer between your agents and this server.
