bissl - menus in Austria

Get a place

get_venue

Read-only

A place by its slug: address, phone, website, opening hours and its whole menu - food, drinks and this week's lunch - with every price.

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": {
      "slug": "<slug>"
    },
    "name": "get_venue"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	The language of dish names, descriptions and section titles: de, the menus' own, or en, as bissl translated them.
`slug`	Yes	The place's `slug`, from a search's or a list's answer.

Output Schema

Name	Required	Description
`email`	No	Its email address, as its own website gives it: "info@figlmueller.at".
`menus`	Yes	Its regular food and drinks, and its lunch of this week; none when bissl has no menu of it.
`phone`	No	Its phone number, Austrian, as dialled from abroad without spaces: "+4315126177".
`place`	Yes
`website`	No	Its own website.
`checked_on`	No	The day its menus were last read from its website, or the day a visitor sent the photos they were read from.
`attribution`	Yes
`menu_source`	No	Where its menus were read: "website", its own website, or "visitor_photo", photos of its printed menu a visitor sent and bissl checked. Null when it has no menu.
`opening_hours`	No	Its opening hours in OpenStreetMap's syntax: "Mo-Fr 11:00-22:00; Sa 12:00-22:00".

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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"
+]

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"
+  ]
+}

Changed3 schema fields changedNov 1, 2026

addedOutput schema / $defs / MenuSource

Added value: +{
+  "description": "Where a place's menus were read.",
+  "oneOf": [
+    {
+      "const": "website",
+      "description": "Its own website.",
+      "type": "string"
+    },
+    {
+      "const": "visitor_photo",
+      "description": "Photos of its printed menu a visitor sent and bissl checked.",
+      "type": "string"
+    }
+  ]
+}

changedOutput schema / properties / checked_on / description

Previous value: -"The day its menus were last read from its website."New value: +"The day its menus were last read from its website, or the day a visitor sent the\nphotos they were read from."

addedOutput schema / properties / menu_source

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/MenuSource"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Where its menus were read: \"website\", its own website, or \"visitor_photo\", photos of\nits printed menu a visitor sent and bissl checked. Null when it has no menu."
+}

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

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / email

Added value: +{
+  "description": "Its email address, as its own website gives it: \"info@figlmueller.at\".",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / phone / description

Added value: +"Its phone number, Austrian, as dialled from abroad without spaces: \"+4315126177\"."

First observedOct 17, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope information about how much data comes back ('its whole menu... with every price', 'this week's lunch'), but stays silent on failure behavior for a bad slug and on data freshness beyond the lunch-week framing.

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: the resource and lookup key come first, then the returned payload as a compact list. Nothing is redundant and no sentence fails to earn its place.

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, the description need not document the response shape, and it correctly focuses on scope ('whole menu', 'this week's lunch'). It is nearly complete for a simple two-parameter read tool; only error and not-found behavior are left unaddressed.

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%, including the origin of the slug and the meaning of the lang enum, so the schema carries the parameter burden. The description only echoes 'by its slug' and says nothing about the language parameter, which is the baseline-3 case.

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?

The description names a specific resource and access path: a single place looked up 'by its slug', returning address, phone, website, hours, and the full menu with prices. That is far more informative than the title 'Get a place'. It stops short of naming a sibling, so the contrast with search_venues is only implied by the word 'slug'.

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 slug-based lookup suggests this is the detail step after a search or list, and the schema notes the slug comes 'from a search's or a list's answer'. There is no explicit 'use this instead of search_venues when...' guidance and no statement of what happens if the slug is unknown.

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?