eatmundo

Server Details

Cross-cuisine dish equivalence with shared-ingredient evidence: 1,956 dishes, 26 cuisines.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 31 days
Last Tested: 2026-10-10 18:10
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-10-06 21:30 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search_dishes discovers dishes, get_recipe retrieves one dish's full details, compare_dishes compares two dishes, find_similar_dishes traverses the equivalence graph, substitute_ingredient replaces a single ingredient, and weekly_menu plans meals. There is no meaningful overlap that would cause misselection, even between compare_dishes and find_similar_dishes.

Naming Consistency4/5

Five tools follow a consistent verb_noun snake_case pattern: compare_dishes, find_similar_dishes, get_recipe, search_dishes, substitute_ingredient. The one deviation is weekly_menu, which is a noun phrase without a verb, but the overall naming remains predictable and readable.

Tool Count5/5

Six tools is well-scoped for a dish/recipe exploration server. Each tool earns its place by covering a distinct operation, and there is no redundant or filler tool.

Completeness5/5

The surface covers the full read-oriented lifecycle: discovery (search_dishes), retrieval (get_recipe), comparison (compare_dishes), equivalence finding (find_similar_dishes), ingredient substitution (substitute_ingredient), and meal planning (weekly_menu). No obvious dead ends exist for the stated domain.

Available Tools

6 tools

compare_dishesCompare two dishesA

Read-onlyIdempotent

Inspect

Compare two dishes ingredient by ingredient: shared items, what is unique to each, a match score, and - for the pairs that have one (nearly 900) - an editorial comparison paragraph in the requested language. Works for any two dishes in the corpus, whether or not they are an edge in the equivalence graph.

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes	First dish: slug or name.
`b`	Yes	Second dish: slug or name.
`lang`	No	Language for titles, ingredient names and URLs.	en

Output Schema

ParametersJSON Schema

Name	Required	Description
`a`	Yes
`b`	Yes
`notes`	Yes
`score`	Yes
`only_a`	Yes
`only_b`	Yes
`paragraph`	Yes
`same_form`	Yes
`attribution`	Yes
`compare_url`	Yes
`score_basis`	Yes
`stored_score`	Yes
`is_graph_edge`	Yes
`below_threshold`	Yes
`excluded_generics`	Yes	Pantry staples deliberately excluded from BOTH the score and the ingredient lists above, because they match almost everything (flour/water/oil/salt/yeast for food, water/salt/sugar for drinks). They are present in the dishes - they are just not evidence of similarity.
`shared_ingredients`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds real behavioral context the annotations cannot: the editorial paragraph exists for only ~900 pairs, so the agent knows output completeness varies by pair.

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?

One front-loaded sentence that leads with the core action and then layers the output detail and the availability caveat. No padding or repetition.

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?

An output schema exists, yet the description still summarizes the return shape and flags the partial-coverage caveat. Nothing needed to invoke or interpret this tool is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning to lang by specifying it drives the editorial paragraph's language, going slightly beyond the schema's 'titles, ingredient names and URLs'.

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?

States a specific verb (compare) and resource (two dishes) and enumerates what the comparison yields: shared items, unique items, match score, and an editorial paragraph. The clause about the equivalence graph implicitly separates it from find_similar_dishes.

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

Usage Guidelines4/5

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

Explicitly states the tool works for ANY two dishes in the corpus, not just graph edges, which tells the agent when this is the right pick over find_similar_dishes. It stops short of naming that sibling or stating exclusions/alternatives outright.

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

find_similar_dishesFind similar dishesA

Read-onlyIdempotent

Inspect

Find dishes from other cuisines that are equivalent to a given dish, from eatmundo's scored equivalence graph (over 10,000 edges across nearly 2,000 recipes from 26 countries). Every edge is evidence-based - shared canonical ingredients - not a language-model guess, and every edge crosses country lines. Use it for "what is the Greek counterpart of lahmacun, and why".

ParametersJSON Schema

Name	Required	Description	Default
`dish`	Yes	Dish to start from: an eatmundo slug (e.g. "lahmacun") or a plain name ("rice pudding"). Names are resolved through site search; check resolved_by in the result.
`lang`	No	Language for titles, ingredient names and URLs.	en
`limit`	No	How many matches to return, best score first. The default of 5 is enough to see whether a cuisine has one clear counterpart or several competing ones.
`country`	No	Restrict matches to one cuisine, ISO 3166-1 alpha-2 (e.g. "GR"). 26 countries are covered.
`min_score`	No	Minimum match score. Defaults to 0 on purpose: 320 dishes only have below-threshold nearest matches, and a default of 50 would silently return nothing for them.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`source`	Yes
`matches`	Yes
`attribution`	Yes
`resolved_by`	Yes
`score_basis`	Yes
`total_matches`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial context beyond the readOnly/idempotent annotations: the results come from a bounded, evidence-based graph of shared canonical ingredients rather than an LLM guess, spanning >10,000 edges, ~2,000 recipes and 26 countries, with every edge crossing country lines. This characterizes the closed-world nature of the dataset consistently with openWorldHint=false.

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

Conciseness4/5

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

Three sentences, purpose front-loaded, then the provenance claim, then the usage example. Every sentence carries information, though the edge-count and country-count statistics are slightly decorative relative to a single-line purpose.

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?

With an output schema present, return values need not be described, and annotations cover the safety profile. The description fully explains what the tool is and what backs its results; only the choice of this tool versus compare_dishes/search_dishes is left unstated.

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 the schema already documents dish resolution, lang enum, limit, country and the deliberately-zero min_score default. The description adds no syntax or format detail beyond that, 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?

States a specific verb ('find'), a precise resource ('dishes from other cuisines equivalent to a given dish'), and names the backing data structure ('eatmundo's scored equivalence graph'). The scoping phrase 'from other cuisines' and 'every edge crosses country lines' implicitly separates it from search_dishes and compare_dishes without needing to open either schema.

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?

Gives a concrete usage context ('what is the Greek counterpart of lahmacun, and why'), which tells the agent when this tool is the right pick. It does not name explicit exclusions or point to sibling tools like compare_dishes, so it falls short of the when-not/alternatives bar for a 5.

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

get_recipeGet recipeA

Read-onlyIdempotent

Inspect

Full recipe for one dish: steps, FAQ, image credit, and ingredients with PARSED quantities (amount, unit, and a normalised base in grams or millilitres where the quantity is measurable). Count-based lines like "3 onions" carry a gram estimate only where a per-item weight is known. Pass servings to rescale the ingredient quantities; the steps keep the original amounts. adaptations lists the diets (vegan, vegetarian, halal, dairy-free, pescatarian) the dish can be fully converted to, with each swap marked substitute (same dish) or adaptation (a different dish).

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Language for titles, ingredient names and URLs.	en
`slug`	Yes	Recipe slug in any of the 7 languages, or a dish name (resolved by search).
`servings`	No	Rescale ingredient quantities to this many servings. The dish's own count is returned as original_servings. Steps are NOT rescaled: they keep the amounts of the original recipe.

Output Schema

ParametersJSON Schema

Name	Required	Description
`faq`	Yes
`url`	Yes
`form`	Yes
`slug`	Yes
`image`	Yes
`notes`	Yes
`steps`	Yes
`title`	Yes
`country`	Yes
`calories`	Yes
`category`	Yes
`servings`	Yes	Servings the ingredient quantities are for (the requested count when servings was passed).
`adaptations`	Yes	Diets this dish does not already fit but can be FULLY converted to - the adapt control shown on the recipe page. A diet is listed only when every disqualifying ingredient has a swap; partial conversions are never offered. Empty when the dish already fits every listed diet, or when no full conversion exists.
`attribution`	Yes
`description`	Yes
`ingredients`	Yes
`match_count`	Yes
`resolved_by`	Yes
`country_name`	Yes
`original_servings`	Yes	Servings the recipe was written for; the steps always describe this count.
`prep_time_minutes`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, not open-world), while the description discloses substantive behavior: quantities are parsed and normalised to grams/ml, count-based lines get gram estimates only when a per-item weight exists, servings rescales ingredients but NOT steps, and adaptations are tagged substitute vs adaptation. This is rich context an agent needs to interpret results correctly.

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

Conciseness4/5

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

Front-loaded with the resource and payload, then details on quantity parsing and rescaling. Dense but every clause carries information; slightly long for a single paragraph but no filler sentences.

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?

With an output schema present, return values need not be explained, yet the description still clarifies the parsed-quantity and adaptations semantics that shape interpretation. It leaves error handling (unresolvable slug, unavailable language) unexplained, a minor gap for a read-only lookup.

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 lang, slug and servings are already documented, including the steps-not-rescaled caveat for servings. The description largely restates that behavior; it adds little 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.

Purpose5/5

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

States a specific verb+resource ('Full recipe for one dish') and enumerates the payload (steps, FAQ, image credit, parsed ingredients, adaptations), which cleanly separates it from search_dishes and compare_dishes. An agent can distinguish it from all siblings 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.

Usage Guidelines3/5

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

Usage is implied rather than stated: the agent infers this is the detail fetch for a single dish given a slug. It explains how servings rescaling works but never says when to prefer this over siblings like search_dishes or substitute_ingredient, nor any prerequisites or exclusions.

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

search_dishesSearch dishesA

Read-onlyIdempotent

Inspect

Search nearly 2,000 dishes from 26 cuisines by text, country, category, preparation technique, or canonical ingredient. Every ingredient in the corpus is linked to a canonical entity, so an ingredient filter also catches translations and spelling variants. Use it to get a slug for the other tools.

ParametersJSON Schema

Name	Required	Description	Default
`form`	No	Preparation technique. One of: soup, stew, stir-fry, grill-roast, fritter, dumpling, stuffed-vegetable, flatbread-pastry, noodle, rice, cold-salad, dip-spread, pickle-ferment, egg, sandwich-wrap, porridge-mash, casserole-bake, cured-preserved, composed-plate, meat-salad, pancake-batter, marinated-cooked, syrup-pastry, fried-dough-sweet, cake, cookie, custard-pudding, sweet-pie-tart, fruit-dessert, frozen, confection, sweet-porridge, glutinous-dumpling, sweet-bread, layered-assembly, filled-pastry, sweet-pancake, starch-gel, hot-infusion, cold-cooler, juice, smoothie-shake, hot-milk-drink, fermented-drink, alcoholic-mixed, alcoholic-brew.
`lang`	No	Language for titles, ingredient names and URLs.	en
`limit`	No	Results per page (max 25).
`query`	No	Free text; needs at least 2 characters to take effect.
`offset`	No	Rows to skip for paging. Pass back the `next_offset` from the previous response; it is null when there is no further page.
`country`	No	ISO 3166-1 alpha-2 cuisine filter.
`category`	No	Dish type. DRINK covers both alcoholic and non-alcoholic; DESSERT is separate from FOOD, so a query for a sweet dish returns nothing under FOOD.
`ingredients`	No	Canonical ingredient names (e.g. ["tomato","garlic"]). A dish matches if it has ANY of them, but results are ranked by how many it has, then by how large a share of the dish's ingredient list they make up (matched / total ingredient lines - among equal matches, dishes with shorter lists come first). Unrecognised names are reported back, not ignored.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`notes`	Yes
`total`	Yes
`offset`	Yes
`attribution`	Yes
`next_offset`	Yes
`unresolved_ingredients`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description still adds real behavioral context: ingredients are linked to canonical entities so filters catch translations and spelling variants, which explains match behavior an agent could not infer from annotations or the schema alone.

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?

Two sentences, both load-bearing: the first establishes corpus scope and filter facets, the second the canonical-ingredient behavior, the third the role in the tool chain. No filler, and the most useful fact (scope and purpose) comes first.

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 an 8-parameter read-only search with a 100%-documented schema and an output schema, the description supplies everything else an agent needs: corpus size, filter dimensions, canonical ingredient matching, and how the result feeds sibling tools. Pagination and return shape are handled by the schema and output schema.

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 every parameter is already documented, including the enum value explanations, the 2-character query floor, and the ranking rule for ingredients. The description's ingredient-linking sentence overlaps the schema rather than extending it, so the baseline 3 for full coverage 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?

States a specific verb and resource ('Search nearly 2,000 dishes from 26 cuisines') and enumerates the five filterable facets. It also positions itself against the ecosystem by noting it is the entry point that produces a slug for the other tools, so an agent can place it relative to get_recipe or find_similar_dishes 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.

Usage Guidelines4/5

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

'Use it to get a slug for the other tools' gives a clear downstream use, implicitly identifying it as the lookup step preceding the sibling detail tools. There is no explicit when-not or named-alternative rule (e.g. when to prefer find_similar_dishes over a query), which keeps it 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.

substitute_ingredientFind an ingredient substituteA

Read-onlyIdempotent

Inspect

Find what can replace a single ingredient, optionally under a dietary constraint (vegan, vegetarian, halal, dairy-free, pescatarian). Each result is marked "substitute" (same dish) or "adaptation" (result is a meaningfully different dish) - most swaps forced by a diet exclusion are adaptations, and the tool says so rather than overselling a swap as if the dish stayed the same. Precomputed and model-verified, not generated on the fly.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Language for titles, ingredient names and URLs.	en
`limit`	No	Max substitutes to return, best first.
`context`	No	Dietary constraint the substitute must satisfy. Omit for the single best general substitute with no diet filter. Other constraints (gluten-free, allergen-free) are not supported - the corpus has no gluten/allergen data, so the tool would have to guess, and it does not.
`ingredient`	Yes	Ingredient name in any of the 7 site languages, or its English canonical form (e.g. "pork belly", "domuz göbeği", "Schweinebauch").

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`context`	Yes
`declined`	Yes	Set instead of an empty substitutes array explaining why there are none - a missing reason is a bug, not a deliberate silence.
`ingredient`	Yes	Resolved canonical (English) ingredient name.
`attribution`	Yes
`resolved_by`	Yes
`substitutes`	Yes
`ingredient_label`	Yes	Ingredient name translated into the requested language.

TDQS

A4.5/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the readOnly/openWorld/idempotent annotations: it discloses the result classification scheme, warns that diet-forced swaps are usually 'adaptations' rather than true substitutes, and states results are 'precomputed and model-verified, not generated on the fly.' This manages agent expectations about result quality and honesty.

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 compact and front-loaded: the core action and constraint are in the first sentence, and the second sentence adds only high-value behavioral caveats. Every clause earns its place, with no redundant wording.

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 rich input schema, output schema, and annotations, the description covers the essential semantics: what the tool does, the supported constraints, the substitute/adaptation distinction, and the precomputed nature of results. Nothing critical is missing 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the context enum and language range. The description mostly reinforces the context parameter and ingredient scope without adding new per-parameter meaning, so the baseline 3 is appropriate.

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 verb+resource pairing, 'Find what can replace a single ingredient,' which clearly distinguishes this tool from dish-level siblings like compare_dishes and find_similar_dishes. It further clarifies the deliverable by defining 'substitute' vs 'adaptation,' so an agent understands exactly what the tool returns.

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 makes the tool's use case explicit: replacing a single ingredient, optionally under a listed dietary constraint such as vegan, vegetarian, halal, dairy-free, or pescatarian. It gives clear context but does not explicitly name sibling tools or state when not to use this tool, stopping short of full exclusion guidance.

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

weekly_menuBuild a weekly menuA

Read-only

Inspect

Build a menu of up to 7 dinners, either one cuisine per day ("world") or all from one country. Honours diet exclusions (pork, beef, meat, fish, dairy, egg, alcohol), vegetarian/vegan/pescatarian requirements, a prep-time ceiling and a budget mode that reuses ingredients. When a constraint cannot be met it is relaxed and the relaxation is reported, never hidden.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	How many days to plan, 1-7.
`lang`	No	Language for titles, ingredient names and URLs.	en
`mode`	No	"world" = a different cuisine each day; "single" = one country.	world
`seed`	No	Same seed + same options = same menu.
`budget`	No	Favour weeks that reuse ingredients across days.
`country`	No	Required when mode is "single".
`exclude`	No	Ingredient attributes to avoid entirely: pork, beef, meat, fish, dairy, egg, alcohol.
`require`	No	Diet every dish must satisfy. This is a WHITELIST and differs from `exclude`, which only removes single ingredient attributes: "vegan" is not the same as excluding meat.
`time_limit`	No	Max prep time in minutes; closed set (30/45/60). The generator relaxes it automatically if too few cuisines qualify, and reports that in relaxations.
`include_extras`	No	Add 2 desserts and 2 drinks (never alcoholic).
`exclude_countries`	No	Cuisines to keep out of the plan, ISO 3166-1 alpha-2. Only meaningful when mode is "world"; excluding too many leaves the generator with too few cuisines to fill the week.

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes
`notes`	Yes
`stats`	Yes
`drinks`	Yes
`desserts`	Yes
`attribution`	Yes
`relaxations`	Yes
`shopping_list`	Yes
`pantry_assumed`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it states that constraint relaxation is always reported and never hidden, and explains budget mode reuses ingredients. There is no contradiction with annotations.

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?

Three sentences with zero filler: first sentence states the core purpose and modes, second summarizes constraints, third guarantees transparency about relaxations. The most important information is front-loaded.

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?

For an 11-parameter tool with an output schema, the description provides a sufficient high-level model—modes, key constraints, and relaxation behavior. It does not mention language, seed, include_extras, or exclude_countries, but those are fully documented in the schema, so this is not a material gap.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds integrative meaning by explaining how diet exclusions, prep-time ceiling, and budget mode combine, clarifying the semantics of exclude, require, time_limit, and budget parameters. It does not enumerate each parameter, but the schema already covers that.

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 states a specific verb and resource: 'Build a menu of up to 7 dinners', with explicit modes ('world' or 'single'). This clearly differentiates it from dish-level siblings like search_dishes and get_recipe, which operate on individual dishes rather than a weekly plan.

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 is implied by the description—this tool builds menus—but there is no explicit when-to-use or when-not-to-use guidance, nor any reference to alternative sibling tools. An agent must infer that a weekly menu request maps to this tool, which is reasonable but not explicitly guided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 6, 2026

Changedget_recipe5 fields changed

addedInput schema / properties / servings

Added value: +{
+  "description": "Rescale ingredient quantities to this many servings. The dish's own count is returned as original_servings. Steps are NOT rescaled: they keep the amounts of the original recipe.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / adaptations

Added value: +{
+  "description": "Diets this dish does not already fit but can be FULLY converted to - the adapt control shown on the recipe page. A diet is listed only when every disqualifying ingredient has a swap; partial conversions are never offered. Empty when the dish already fits every listed diet, or when no full conversion exists.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "diet": {
+        "enum": [
+          "vegan",
+          "vegetarian",
+          "halal",
+          "dairy-free",
+          "pescatarian"
+        ],
+        "type": "string"
+      },
+      "result": {
+        "description": "same_dish when every swap is a like-for-like substitute; different_dish when at least one swap is an adaptation.",
+        "enum": [
+          "same_dish",
+          "different_dish"
+        ],
+        "type": "string"
+      },
+      "swaps": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "ingredient": {
+              "type": "string"
+            },
+            "kind": {
+              "enum": [
+                "substitute",
+                "adaptation"
+              ],
+              "type": "string"
+            },
+            "replacement": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "ingredient",
+            "replacement",
+            "kind"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "diet",
+      "result",
+      "swaps"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / original_servings

Added value: +{
+  "description": "Servings the recipe was written for; the steps always describe this count.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

addedOutput schema / properties / servings / description

Added value: +"Servings the ingredient quantities are for (the requested count when servings was passed)."

changedOutput schema / required

Previous value: -[
-  "slug",
-  "title",
-  "country",
-  "country_name",
-  "category",
-  "form",
-  "prep_time_minutes",
-  "url",
-  "description",
-  "calories",
-  "servings",
-  "steps",
-  "faq",
-  "ingredients",
-  "image",
-  "match_count",
-  "resolved_by",
-  "notes",
-  "attribution"
-]New value: +[
+  "slug",
+  "title",
+  "country",
+  "country_name",
+  "category",
+  "form",
+  "prep_time_minutes",
+  "url",
+  "description",
+  "calories",
+  "servings",
+  "original_servings",
+  "steps",
+  "faq",
+  "ingredients",
+  "image",
+  "adaptations",
+  "match_count",
+  "resolved_by",
+  "notes",
+  "attribution"
+]

1 tool updateOct 5, 2026

Changedsearch_dishes1 field changed

changedInput schema / properties / ingredients / description

Previous value: -"Canonical ingredient names (e.g. [\"tomato\",\"garlic\"]). A dish matches if it has ANY of them, but results are ranked by how many it has. Unrecognised names are reported back, not ignored."New value: +"Canonical ingredient names (e.g. [\"tomato\",\"garlic\"]). A dish matches if it has ANY of them, but results are ranked by how many it has, then by how large a share of the dish's ingredient list they make up (matched / total ingredient lines - among equal matches, dishes with shorter lists come first). Unrecognised names are reported back, not ignored."

1 tool updateSep 23, 2026
- Addedsubstitute_ingredient

3 tool updatesSep 16, 2026

Changedfind_similar_dishes1 field changed

addedInput schema / properties / limit / description

Added value: +"How many matches to return, best score first. The default of 5 is enough to see whether a cuisine has one clear counterpart or several competing ones."

Changedsearch_dishes3 fields changed

addedInput schema / properties / category / description

Added value: +"Dish type. DRINK covers both alcoholic and non-alcoholic; DESSERT is separate from FOOD, so a query for a sweet dish returns nothing under FOOD."

addedInput schema / properties / limit / description
```
Added value: +"Results per page (max 25)."
```

addedInput schema / properties / offset / description

Added value: +"Rows to skip for paging. Pass back the `next_offset` from the previous response; it is null when there is no further page."

Changedweekly_menu3 fields changed

addedInput schema / properties / days / description
```
Added value: +"How many days to plan, 1-7."
```

addedInput schema / properties / exclude_countries / description

Added value: +"Cuisines to keep out of the plan, ISO 3166-1 alpha-2. Only meaningful when mode is \"world\"; excluding too many leaves the generator with too few cuisines to fill the week."

addedInput schema / properties / require / description

Added value: +"Diet every dish must satisfy. This is a WHITELIST and differs from `exclude`, which only removes single ingredient attributes: \"vegan\" is not the same as excluding meat."

1 tool updateSep 10, 2026

Changedcompare_dishes2 fields changed

addedOutput schema / properties / excluded_generics

Added value: +{
+  "description": "Pantry staples deliberately excluded from BOTH the score and the ingredient lists above, because they match almost everything (flour/water/oil/salt/yeast for food, water/salt/sugar for drinks). They are present in the dishes - they are just not evidence of similarity.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "a",
-  "b",
-  "score",
-  "score_basis",
-  "is_graph_edge",
-  "stored_score",
-  "below_threshold",
-  "same_form",
-  "shared_ingredients",
-  "only_a",
-  "only_b",
-  "paragraph",
-  "compare_url",
-  "notes",
-  "attribution"
-]New value: +[
+  "a",
+  "b",
+  "score",
+  "score_basis",
+  "is_graph_edge",
+  "stored_score",
+  "below_threshold",
+  "same_form",
+  "shared_ingredients",
+  "only_a",
+  "only_b",
+  "excluded_generics",
+  "paragraph",
+  "compare_url",
+  "notes",
+  "attribution"
+]

5 tool updatesSep 10, 2026
- First observedcompare_dishes
- First observedfind_similar_dishes
- First observedget_recipe
- First observedsearch_dishes
- First observedweekly_menu

Related MCP Connectors

Symmap A
io.github.pipeworx-io
SymMap v2 — Traditional Chinese Medicine association graph from symmap.org
Biology & Medicine Research & Data Open Data
1
Conceptnet A
io.github.pipeworx-io
ConceptNet MCP — open multilingual word/phrase relation graph
Knowledge & Memory AI & Machine Learning
2
Cantara wiki — community knowledge web A
no.cantara
Norwegian open-source community wiki (2,290 articles, 2008-2022) as a signed KCP knowledge web.
Knowledge & Memory Open Data
52
TownRoster Local Business Intelligence
io.github.PhotoRomano
OSM-sourced local business data across 9 niches — cuisine, dietary options, delivery, accessibility.
Location Services Open Data Search
1

Related MCP Servers

menus-mcp
Search Knowledge & Memory
spyyps
F
license
Not graded
quality
C
maintenance
Recommends dishes from a global cuisine knowledge base based on user preferences (keywords, cuisine, price, etc.) via weighted random selection with bias correction and diversity.
Updated 4 months ago (2026-06-16 06:21 UTC)
-
unfragile-mcp-server
Search AI & Machine Learning Developer Tools
Savirinc
A
license
A
quality
D
maintenance
The match graph for AI. Search 100K+ capabilities across 13K+ AI artifacts.
Updated 4 months ago (2026-05-27 10:21 UTC)
10
63 npm
2
MIT
grant-mcp
Research & Data Government Data Search
vertical-mcp
A
license
B
quality
D
maintenance
MCP server for searching research grants across NSF (US), ERC (EU), and KRF/NRF (Korea) via a unified interface. NIH excluded—covered by existing connectors.
Updated 6 months ago (2026-04-21 08:25 UTC)
3
9 npm
MIT
korean-vocational-learning-map
Education & Learning Tools Open Data
raphysicst-create
A
license
Not graded
quality
B
maintenance
MCP server providing a local learning graph for the Korean vocational high school curriculum (2022 revised), including 8,425 achievement standards, topics, and 10 tools for searching standards, topics, prerequisites, and learning roadmaps.
Updated 2 months ago (2026-08-25 02:16 UTC)
50 npm
2
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?