LUT Lunch MCP

Find dishes

find_dishes

Read-onlyIdempotent

Search LUT Skinnarila campus lunch menus by dish name, diet, or allergen across days and restaurants. Returns matching dishes with date and restaurant to support lunch planning.

Instructions

Search LUT Skinnarila campus lunch menus for dishes matching a word, diet or allergen restriction, across several days and restaurants. Use it for questions like "any vegan options this week?", "where is something gluten-free tomorrow?" or "is there salmon this week?". Returns a flat list of matching dishes with date and restaurant. Searches Finnish and English dish names; if an English word finds nothing, try the Finnish one (e.g. "lohi" for salmon). Past dates are searched in the recorded history, up to 14 days per search; for "how often" or "when last" over longer periods use menu_stats.

Input Schema

Name	Required	Description	Default
`to`	No	Last day to search (at most 14 days). Default: from + 6 days.
`diet`	No	Only dishes labelled with every one of these diets.
`from`	No	First day to search. Default: today.	today
`limit`	No	Maximum matches to return (1–100). Default: 30.
`query`	No	Word or part of a dish name, in English or Finnish (e.g. "salmon" or "lohi").
`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
`today`	Yes
`notice`	Yes
`matches`	Yes
`searched`	Yes
`timezone`	Yes
`truncated`	Yes
`unverifiable`	Yes
`total_matches`	Yes
`days_without_data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.1Oct 27, 2026

changedOutput schema / properties / days_without_data / items / properties / reason / enum

Previous value: -[
-  "weekend",
-  "public_holiday",
-  "none_listed",
-  "not_published_yet",
-  "history_not_available",
-  "source_unavailable",
-  "source_error"
-]New value: +[
+  "weekend",
+  "public_holiday",
+  "none_listed",
+  "not_published_yet",
+  "history_not_available",
+  "source_unavailable",
+  "source_error",
+  "history_unavailable"
+]

Changed3 schema fields changedv0.2.0Oct 24, 2026

addedOutput schema / properties / days_without_data / items / properties / holiday_name
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / days_without_data / items / properties / reason / enum

Previous value: -[
-  "weekend",
-  "public_holiday",
-  "none_listed",
-  "not_published_yet",
-  "history_not_available",
-  "source_unavailable"
-]New value: +[
+  "weekend",
+  "public_holiday",
+  "none_listed",
+  "not_published_yet",
+  "history_not_available",
+  "source_unavailable",
+  "source_error"
+]

changedOutput schema / properties / days_without_data / items / required

Previous value: -[
-  "date",
-  "restaurant_id",
-  "status",
-  "reason"
-]New value: +[
+  "date",
+  "restaurant_id",
+  "status",
+  "reason",
+  "holiday_name"
+]

First observedv0.1.0Oct 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), yet the description adds real substance beyond them: it discloses the return shape ('a flat list of matching dishes with date and restaurant'), states that past dates come from recorded history and are capped at 14 days per search, and warns that dishes with unpublished allergens are dropped and counted as 'unverifiable'. That last point is a non-obvious behavioral quirk that would otherwise cause an agent to misread an empty list as 'no such dishes exist'.

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?

Roughly four sentences, front-loaded with scope, then examples, then return behavior, then the sibling hand-off and the language fallback. No sentence is filler: the examples, the 14-day cap, and the Finnish retry rule each change agent behavior. Structure mirrors the order an agent needs them.

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?

Even with 8 parameters and an output schema present, the description covers the pieces structured fields can't express: the 14-day history window, the language fallback, the allergen 'unverifiable' drop behavior, and the boundary against menu_stats. An agent has everything needed to call this correctly and interpret an empty result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning the schema cannot: it links `query` and `language` by explaining that names exist in both Finnish and English and that a miss in one should be retried in the other, which changes how those two parameters should be sequenced. It also frames `exclude_allergens` as a semantic exclusion (contain *or may contain*) rather than a plain field filter, matching the schema's 'unverifiable' note.

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 opens with a specific verb and resource ('Search LUT Skinnarila campus lunch menus for dishes') and immediately names the dimensions it filters on: word, diet, allergen, across days and restaurants. The closing sentence explicitly distinguishes it from menu_stats ('for "how often" or "when last" over longer periods use menu_stats'), so an agent can separate it from the three siblings without reading a schema.

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 concrete trigger questions ('any vegan options this week?', 'where is something gluten-free tomorrow?') that map directly onto parameter combinations, plus an explicit exclusion routing aggregate questions to menu_stats. It also supplies an operational fallback rule — if an English word finds nothing, retry in Finnish (e.g. 'lohi') — which is exactly the kind of usage guidance that prevents empty-result retries.

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

Deploy Server