bissl - menus in Austria

Search dishes

search_dishes

Read-only

Find a dish or drink on the menus of places in Austria: which places serve it, at what price, with diet and allergens. Give the dish in plain words ("schnitzel", "vegan curry", "glutenfreie pizza"), and where: a point (lat, lon) to search near, a map area (bbox), or neither for everywhere. A word for a kind of dish ("pizza", "schnitzel", "weißwein") finds the dishes of that kind whatever they are called - a Margherita for "pizza" - and each dish carries its categories.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_dishes"
  }
}

Input Schema

Name	Required	Description
`q`	No	Words a dish must match, as people say them, German or English: "schnitzel", "vegan curry", "glutenfreie pizza". A diet, allergens or a cuisine among them are taken as filters; misspelt German words are put right when that finds something.
`lat`	No	The latitude of a point - the user's, or one they name - to measure distances from and sort nearest first; with `lon`.
`lon`	No	The longitude of that point; with `lat`.
`bbox`	No	Keep to a map area: "west,south,east,north" in degrees - a town, a district, the streets around a place. Everywhere when left out.
`diet`	No	Only dishes of this diet: vegan, or vegetarian (vegan dishes included).
`lang`	No	The language of dish names, descriptions and section titles: de, the menus' own, or en, as bissl translated them.
`sort`	No	The order of the places.
`limit`	No	Places to answer with: 1 to 30, 10 when left out.
`offset`	No	Places to skip, for the next ones: 0 when left out.
`cuisine`	No	Only at places of this cuisine, as OpenStreetMap names it: "italian", "vietnamese".
`free_of`	No	Only dishes whose menu lists their allergens and none of these letters: "A" gluten, "G" milk, "AG" both.
`open_now`	No	Only places open right now.
`dish_kind`	No	Food or drinks only.
`max_price`	No	Only dishes costing at most this much, in whole euros.
`min_price`	No	Only dishes costing at least this much, in whole euros.

Output Schema

Name	Required	Description
`diet`	No	The filters in effect, asked for or taken from the words.
`note`	No	Why there is nothing, or less than asked for, when there is a reason to say.
`places`	Yes	Each with its best matches, at most 5.
`cuisine`	No
`free_of`	No
`category`	No	The dish categories read from the words, as slugs listed in `/v1/openapi.json`: "pizza" is `[{"category": "pizza", "dish": null}]`. They are alternatives - a dish of any of them is found - and a word naming a dish ("margherita") names its category with that dish. Null when the words named none.
`searched`	No	The words searched for, once a diet, allergens or a cuisine among them were taken as filters ("vegan curry" searches "curry" with diet vegan); null for none.
`corrected`	No	The words put right when they found nothing as typed: "schnitzel" for "schnitzl".
`attribution`	Yes
`recommended`	Yes	Nothing was asked for, so these are dishes popular at this time of day.
`total_dishes`	Yes
`total_places`	Yes	Places and dishes found, of which `places` holds `limit` from `offset` on. A search reads at most 500 places - the nearest `lat`, `lon`, else the middle of `bbox`, else the most complete listings - and counts the dish where those have it; when fewer than 30 do, it reads the 500 nearest (or most complete) that have it instead. So these are at most 500, `sort=price` is the cheapest of them, and paging ends there.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 8, 2026

addedOutput schema / $defs / ApiCategory

Added value: +{
+  "description": "What a dish is, from bissl's list of dish categories: a category and, when it names one,\nthe dish of it. Both are slugs - \"pizza\" and \"margherita\", \"schnitzel\", \"weisswein\" - listed\nin `/v1/openapi.json`.",
+  "properties": {
+    "category": {
+      "description": "The category's slug: \"pizza\", \"pasta\", \"schnitzel\", \"weisswein\"...",
+      "type": "string"
+    },
+    "dish": {
+      "description": "The dish of that category, by its slug: \"margherita\" for \"pizza\". Null when the\ncategory is all that is known, or all that was asked for.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "category"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / Dish / properties / categories

Added value: +{
+  "description": "What the dish is, from bissl's list - the categories (and their dishes) its name and\ndescription are read to be, as slugs listed in `/v1/openapi.json`: \"pizza\" with dish\n\"margherita\". A search for a category's word finds these whatever they are called.\nEmpty when bissl has not read it, or it is of no category on the list.",
+  "items": {
+    "$ref": "#/$defs/ApiCategory"
+  },
+  "type": "array"
+}

changedOutput schema / $defs / Dish / required

Previous value: -[
-  "id",
-  "name",
-  "description",
-  "prices",
-  "url"
-]New value: +[
+  "id",
+  "name",
+  "description",
+  "prices",
+  "categories",
+  "url"
+]

addedOutput schema / properties / category

Added value: +{
+  "description": "The dish categories read from the words, as slugs listed in `/v1/openapi.json`:\n\"pizza\" is `[{\"category\": \"pizza\", \"dish\": null}]`. They are alternatives - a dish\nof any of them is found - and a word naming a dish (\"margherita\") names its category\nwith that dish. Null when the words named none.",
+  "items": {
+    "$ref": "#/$defs/ApiCategory"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

Changed1 schema field changedNov 2, 2026

addedOutput schema / $defs / Place / properties / part_of

Added value: +{
+  "description": "The larger place it is part of, as its own website names it - the hotel, castle or\nclub its restaurant or bar is in: \"Das Schloss an der Eisenstrasse\". Null for none.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedOct 22, 2026

changedOutput schema / $defs / Place / properties / price_level / description

Previous value: -"\"€\" to \"€€€€\" from its menu's prices; null while bissl doesn't know."New value: +"\"€\" to \"€€€€\" from its menu's prices, against places of its kind - a restaurant's\nmains, a café's coffee and cake, a bar's cocktails; null while bissl doesn't know."

Changed1 schema field changedOct 18, 2026

changedOutput schema / properties / total_places / description

Previous value: -"Places and dishes found, of which `places` holds `limit` from `offset` on."New value: +"Places and dishes found, of which `places` holds `limit` from `offset` on. A search\nreads at most 500 places - the nearest `lat`, `lon`, else the middle of `bbox`, else\nthe most complete listings - and counts the dish where those have it; when fewer than\n30 do, it reads the 500 nearest (or most complete) that have it instead. So these\nare at most 500, `sort=price` is the cheapest of them, and paging ends there."

First observedOct 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare a read-only, closed-world search, so the description builds usefully on that: diet, allergen and cuisine words inside `q` are silently promoted to filters, misspelt German is corrected, and generic terms expand via each dish's `categories`. Those are non-obvious behaviors an agent could not infer from the annotations or schema.

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 purpose, then input format, then matching behavior; each sentence carries real information. It is a single dense paragraph with some example repetition from the schema ('schnitzel', 'pizza'), but nothing is genuinely wasteful.

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 a 15-parameter, all-optional search with a full output schema and read-only annotations, the description covers the two things that matter most: how to phrase the query and how to scope geography. Remaining parameters are fully documented in the schema, so nothing required for a correct call 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 description coverage is 100%, so the baseline is 3; the description earns extra by explaining the three mutually exclusive location modes and what happens when none is supplied, plus the natural-language semantics of `q`. Filtering parameters such as diet, free_of, sort and limit are left entirely to the schema, which is acceptable given the coverage.

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 ('Find a dish or drink on the menus of places in Austria') plus what it returns: which places serve it, price, diet and allergens. This is clearly distinct from search_venues (places) and search_lunch_menus (menus), so an agent can route 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 Guidelines4/5

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

Gives concrete input guidance: plain-word dishes, and a location as a point (lat, lon), a bbox, or neither for everywhere. It also explains the kind-matching behavior for generic words like 'pizza'. It stops short of naming when to prefer search_venues or search_lunch_menus, so it is clear but not fully comparative.

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

All bissl - menus in Austria 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?