Skip to main content
Glama

Search dishes

search_dishes
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formNoPreparation 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.
langNoLanguage for titles, ingredient names and URLs.en
limitNoResults per page (max 25).
queryNoFree text; needs at least 2 characters to take effect.
offsetNoRows to skip for paging. Pass back the `next_offset` from the previous response; it is null when there is no further page.
countryNoISO 3166-1 alpha-2 cuisine filter.
categoryNoDish type. DRINK covers both alcoholic and non-alcoholic; DESSERT is separate from FOOD, so a query for a sweet dish returns nothing under FOOD.
ingredientsNoCanonical 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

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
notesYes
totalYes
offsetYes
attributionYes
next_offsetYes
unresolved_ingredientsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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."
  2. Changed3 schema 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."
  3. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources