Dishes, prices, diets, allergens and this week's lunch menus of places to eat in Austria.
Scored across 4 tools
get_venue is a single-venue fetch while search_venues, search_dishes, and search_lunch_menus are distinct search axes (venue, dish, lunch menu). There is mild overlap since search_venues can filter to "serving lunch today" and search_dishes may surface lunch dishes, but the primary intent of each tool is clear.
All four tools use a consistent snake_case verb_noun pattern: get_venue, search_dishes, search_lunch_menus, search_venues. The singular/plural nouns are logical and easy to predict.
Four tools is well-scoped for a menu discovery service: one fetch-by-id and three targeted search entry points. Each tool covers a genuinely different lookup mode, with no redundant or filler tools.
The read-only surface covers the domain's key access patterns: venue lookup, venue discovery with rich filters, dish/drink search, and time-based lunch menu search. No obvious lifecycle or query gaps remain for a directory-style server.
A place by its slug: address, phone, website, opening hours and its whole menu - food, drinks and this week's lunch - with every price.
| 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. |
| Name | Required | Description |
|---|---|---|
| menus | Yes | Its regular food and drinks, and its lunch of this week; none when bissl has no menu of it. |
| phone | No | |
| place | Yes | |
| website | No | Its own website. |
| checked_on | No | The day its menus were last read from its website. |
| attribution | Yes | |
| opening_hours | No | Its opening hours in OpenStreetMap's syntax: "Mo-Fr 11:00-22:00; Sa 12:00-22:00". |
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 payload-scope context (whole menu plus this week's lunch with every price), but says nothing about auth, rate limits, error behavior, or what happens with an unknown slug.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence identifying the key and the returned content; no filler. The nested dash clause listing food, drinks and lunch is slightly ornate but still earns its place by scoping the payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return shape need not be restated, and the description correctly focuses on resource identity and payload breadth. The only material gap is routing guidance relative to the search siblings, which the annotations and schema cannot supply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself explains both slug (source of the value) and lang (language of dish names). The description adds nothing about lang and only gestures at slug via 'by its slug', so it stays at the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and retrieval key ('a place by its slug') and enumerates the payload (address, phone, website, hours, full menu, prices). It is clearly a single-entity detail fetch and thus distinct from the search_* siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The slug-based fetch implies a two-step workflow after search_venues, but the description never states when to prefer this over the search siblings or what to do if the slug is unknown. Usage is left to inference from the required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 | |
| 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. |
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 real context beyond that: the data covers places in Austria (consistent with the closed-world hint), results include which venues serve the dish along with price, diet and allergens, and free-text terms for diets/allergens/cuisines are silently promoted to filters. No pagination or rate-limit behavior is mentioned, but limit/offset live in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the outcome ('Find a dish or drink... which places serve it, at what price, with diet and allergens') followed by the input contract. No filler. The location clause partially duplicates the schema's lat/lon/bbox descriptions, which keeps it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explain return values, and it correctly focuses on scope (Austria) and query phrasing. All 15 parameters are documented in the schema, so nothing essential is missing. It could be more complete by routing the agent away from sibling search tools, but for a 15-param optional-argument search this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the 15 parameters carries a substantive description, so the schema does the heavy lifting. The description only restates the headline inputs (q, lat/lon, bbox) without adding format or syntax detail beyond what the schema already says. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: find a dish or drink on menus, returning which places serve it with price, diet and allergens, scoped to Austria. That is far more than a restatement of the name. It stops short of differentiating from siblings such as search_lunch_menus or search_venues, so an agent must infer the boundary between menu-item search and venue search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent how to phrase the query (plain words, German or English) and gives three location modes: a point, a bbox, or neither for everywhere. That is genuine call-shaping guidance. However, it never says when to prefer this tool over search_lunch_menus, search_venues or get_venue, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Places to eat and drink: by name, kind, cuisine, map area or nearness, open now, with a menu, serving lunch today.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words to search for among the places: part of a name - "figlm" finds Figlmüller. | |
| 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. | |
| kind | No | Its kind as OpenStreetMap tags it: restaurant, fast_food, cafe, bar, pub, biergarten, ice_cream, food_court, bakery or pastry. | |
| 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". | |
| has_menu | No | Only places whose menu with prices bissl read. | |
| open_now | No | Only places open right now. | |
| lunch_today | No | Only places serving a lunch menu today. |
| Name | Required | Description |
|---|---|---|
| note | No | Why there is nothing, when there is a reason to say. |
| places | Yes | |
| cuisine | No | The cuisine kept to, when one was asked for. |
| attribution | Yes | |
| total_places | Yes | Places matching, of which `places` holds `limit` from `offset` on. |
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 little beyond restating filter dimensions and doesn't mention defaults, pagination behavior, or result limits beyond what the schema says.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that lists capabilities compactly. It is efficient, though the list-like phrasing reads as a feature dump rather than a prioritized guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 optional parameters, full schema documentation, an output schema, and safety annotations, the description covers the tool's identity adequately. It could be stronger by distinguishing this tool from its search siblings, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented in detail, including bbox format, sort modes, and limits. The description's phrases ('open now', 'with a menu', 'serving lunch today') simply echo parameter names without adding meaning, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool searches over (places to eat and drink) and enumerates the searchable dimensions, which is clear enough to select it. It doesn't explicitly contrast with sibling search_dishes or search_lunch_menus, so an agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the enumerated filters (by name, cuisine, map area, open now) but there is no explicit guidance on when to prefer this over search_dishes or search_lunch_menus, nor any prerequisite or exclusion notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_venuesearch_dishessearch_lunch_menussearch_venuesAI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Austrian energy data: 119 electricity tariffs daily, grid fees, subsidies, bill analysis.
5 lakh+ Indian restaurants: menus with prices, timings, phones and dish search. Free, no API key.
Austria's official company register (Firmenbuch) – master data, financials & ratios for AI agents.
Add one secure layer between your agents and this server.
