bissl - menus in Austria

Search lunch menus

search_lunch_menus

Read-only

The lunch menus (Mittagsmenüs) served today - or another day of this week - with every dish and its price, near a point or in a map area; with q, only the lunch dishes matching it ("schnitzel", "suppe"). A word for a kind of dish ("pizza", "schnitzel") finds the dishes of that kind whatever they are called, 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_lunch_menus"
  }
}

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.
`day`	No	"2026-10-20": another day of this lunch week, Monday to Sunday (at the weekend, the coming week's too). Today when left out; open_now only counts today.
`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.
`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
`day`	Yes	The day the lunch menus are for.
`diet`	No	The filters in effect, asked for or taken from the words.
`note`	No	Why there is nothing, when there is a reason to say.
`places`	Yes	Each with its whole lunch that day - the dishes matching `q`, when it was given.
`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 the dishes match, once a diet, allergens or a cuisine among them were taken as filters; null for none.
`corrected`	No	The words put right when they found nothing as typed: "schnitzel" for "schnitzl".
`attribution`	Yes
`total_dishes`	Yes
`total_places`	Yes	Places serving lunch and their dishes, of which `places` holds `limit` from `offset` on.

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

First observedOct 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavior beyond that: each dish carries prices and its `categories`, the dish-kind matching is semantic rather than literal name matching, and it clarifies the week window and that open_now only counts today.

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?

Two sentences, front-loaded with what the tool returns before the `q` and dish-kind nuances. The em-dash and semicolon construction is dense and slightly run-on, but every clause carries information.

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 read-only search with an output schema and annotations, the description covers the main modes (time, location, query) adequately. Remaining details such as pagination and sort defaults live in the schema, which is acceptable given full coverage.

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 explains q, day, bbox, diet, sort, limits, and price bounds in detail. The description reinforces the q semantics (kind-of-dish matching) and the point/map-area pair, but adds little the schema does not already say, so the 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?

States a specific verb and resource (search lunch menus), the time scope (today or another day of this week), what comes back (every dish with its price), and the two spatial modes. It does not explicitly distinguish itself from siblings like search_dishes, so an agent must infer the boundary, but the purpose itself is unambiguous.

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 context is implied rather than stated: it is for lunch menus today or this week, `q` narrows to matching lunch dishes, and it works near a point or inside a map area. There is no explicit when-not guidance or named alternative (e.g. 'use search_dishes for dishes outside lunch menus'), which is the main gap.

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?