eatmundo

Find similar dishes

find_similar_dishes

Read-onlyIdempotent

Find dishes from other cuisines that are equivalent to a given dish, from eatmundo's scored equivalence graph (thousands of 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".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dish": "<dish>"
    },
    "name": "find_similar_dishes"
  }
}

Input 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

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."

First observedSep 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Adds real value beyond the annotations: results are evidence-based (shared canonical ingredients, not LLM guesses), every edge is guaranteed to cross country lines, and the corpus is finite (2,000 recipes, 26 countries) — consistent with openWorldHint=false. It doesn't address result ordering edge cases or what happens when no match exists, which the min_score schema note only partially covers.

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, front-loaded with the core action, then provenance, then a usage example. The corpus-size clause is slightly promotional but earns some place by signaling the closed dataset size.

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 and full schema coverage, the description only needs to convey intent, data provenance, and scope — all present. The one remaining gap is guidance on the relationship to compare_dishes when the agent has two known dishes in hand.

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%, and the schema already explains dish resolution, limit, country, and the deliberate min_score default. The description's "and why" hints that returned matches carry justification, but it adds no parameter-level detail beyond the schema; baseline 3 applies.

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

Purpose4/5

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

Specific verb+resource with scope: returns dishes from *other cuisines* equivalent to a given dish, sourced from a scored equivalence graph. The cross-cuisine, one-to-many framing implicitly separates it from compare_dishes (pairwise) and search_dishes, but no sibling is named, which is the main confusion risk.

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 triggering question pattern ("what is the Greek counterpart of lahmacun, and why"), which tells the agent the intended use case well. It stops short of stating exclusions or naming compare_dishes/search_dishes as alternatives for other needs.

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

All eatmundo tools Inspect

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?