LUT Lunch MCP

Get lunch menus

get_menu

Read-onlyIdempotent

Retrieve lunch menus for LUT Skinnarila campus restaurants for one or more consecutive days, including past dates. Use it to check what is or was served and why a menu is unavailable.

Instructions

Get lunch menus for LUT University's Skinnarila campus restaurants (Lappeenranta, Finland) for one day or several consecutive days, including past days from the recorded history. Use it to show what is or was served, e.g. "what's for lunch today?" or "what was on last Tuesday?". To look for a particular dish, ingredient, diet or allergen across days and restaurants, use find_dishes; for "how often" and "when last", use menu_stats. Pass "today" or "tomorrow" rather than computing dates yourself; dates are in Finland time. Restaurants without a menu are still listed with a reason (weekend, public holiday, not published yet, no history for that day, source unavailable).

Input Schema

Name	Required	Description	Default
`date`	No	"today", "tomorrow" or a date as YYYY-MM-DD (Finland time).	today
`days`	No	Number of consecutive days starting from `date` (1–7). Default: 1.
`diet`	No	Only dishes labelled with every one of these diets.
`language`	No	Language for dish and course names. Default: en.	en
`restaurants`	No	Restaurant ids to include. Default: all.
`exclude_allergens`	No	Leave out dishes that contain or may contain these allergens. Dishes whose allergens are not published are left out too and counted as "unverifiable".

Output Schema

Name	Required	Description	Default
`days`	Yes
`today`	Yes
`notice`	Yes
`timezone`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.1Oct 27, 2026

changedOutput schema / properties / days / items / properties / restaurants / items / properties / reason / anyOf

Previous value: -[
-  {
-    "enum": [
-      "weekend",
-      "public_holiday",
-      "none_listed",
-      "not_published_yet",
-      "history_not_available",
-      "source_unavailable",
-      "source_error"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "weekend",
+      "public_holiday",
+      "none_listed",
+      "not_published_yet",
+      "history_not_available",
+      "source_unavailable",
+      "source_error",
+      "history_unavailable"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedv0.2.0Oct 24, 2026

changedOutput schema / properties / days / items / properties / restaurants / items / properties / reason / anyOf

Previous value: -[
-  {
-    "enum": [
-      "weekend",
-      "public_holiday",
-      "none_listed",
-      "not_published_yet",
-      "history_not_available",
-      "source_unavailable"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "weekend",
+      "public_holiday",
+      "none_listed",
+      "not_published_yet",
+      "history_not_available",
+      "source_unavailable",
+      "source_error"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv0.1.0Oct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only/idempotent/open-world annotations, the description discloses important behavior: menus can cover past days from recorded history, dates use Finland time, and restaurants without a menu are still returned with a reason such as weekend, public holiday, not published yet, no history, or source unavailable.

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?

The description is front-loaded with the core purpose, then adds usage examples, sibling routing, date guidance, and missing-menu behavior in a compact sequence. Each sentence carries useful information for selecting or invoking the tool.

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 a read-only, six-parameter tool with full schema description coverage and an output schema, the description supplies everything needed: scope, historical coverage, timezone handling, alternative tools, and fallback behavior when a restaurant has no menu.

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?

The schema already documents all six parameters at 100% coverage, so the baseline is 3. The description adds useful semantic context by clarifying that "date" can cover past days from recorded history and by advising "today"/"tomorrow" instead of computed dates because dates are in Finland time.

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?

The description states a specific verb and resource: getting lunch menus for LUT University's Skinnarila campus restaurants for one or several consecutive days, including past days. It clearly distinguishes this lookup tool from find_dishes and menu_stats by naming the specific questions it answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives explicit usage conditions with examples such as "what's for lunch today?" and "what was on last Tuesday?", and names alternatives for related needs: find_dishes for searching a particular dish/ingredient/diet/allergen, and menu_stats for frequency or last-served questions. It also tells the caller to pass "today" or "tomorrow" rather than computing dates.

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

Deploy Server