EduPage MCP Server

rate_meal

DestructiveIdempotent

Submit a student's taste and portion scores for a canteen meal by date and meal type, replacing any earlier rating for that slot.

Instructions

Rate the taste and portion size of a meal. Writes: submits both scores and overwrites whatever rating this account's student already gave for that date and meal type.

One rating per (date, meal_type), filed against the student the session is logged in as. It replaces the previous rating outright — no history is kept and no tool here undoes it — so the call is safe to repeat with the same scores, but changing a score means submitting again and losing the old one.

Rate a meal the student actually ate. Read get_meals first to confirm the slot is published and to see the current averages. Not an ordering tool: choose_meal books a menu and sign_off_meal releases the booking, and neither records a rating. Only the three canteen slots can be rated — breakfast and dinner, which get_meals also returns, carry no rating board and fail with "No 'breakfast' meal available".

Args: date_str: YYYY-MM-DD of the meal that was eaten. meal_type: 'snack' | 'lunch' | 'afternoon_snack' — the slots choose_meal and sign_off_meal also accept, and the only ones with a rating board. quality: Taste, 1 (inedible) to 5 (excellent), integer. quantity: Portion size, 1 (far too little) to 5 (far too much), integer. Submitted in the same request as quality; neither score can be left out or rated on its own. subdomain: School to query (defaults to the active subdomain).

Returns: dict: {'rated': True, 'meal_type', 'date'}. The scores are not echoed back — re-read get_meals to confirm what was recorded.

Notes: - Fails with "No rating available for this meal" when the school has not opened ratings for that menu, and with a "Missing boarder id" error when the session carries no canteen list to file the score against — switch_to_student first if one login covers several children. - The score posts to the school's canteen endpoint under that dining id and counts towards the averages get_meals shows, so it reaches the canteen and cannot be deleted through this server. - Upstream sends a fixed meal-slot field ("jedlo_dna" = 2, lunch) with the rating, so a snack or afternoon-snack score is recorded against the lunch entry.

Input Schema

Name	Required	Description	Default
`quality`	Yes
`date_str`	Yes
`quantity`	Yes
`meal_type`	Yes
`subdomain`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Oct 2, 2026
- addedInput schema / properties / subdomain / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / subdomain / type
```
Removed value: -"string"
```
First observedv0.4.6Sep 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructive/idempotent/openWorld, but the description adds far more: the previous rating is overwritten outright with no history and no undo tool, re-submitting with the same scores is safe, scores are not echoed back, and it discloses failure modes plus an upstream quirk (snack scores recorded against the lunch 'jedlo_dna' entry). This is unusually rich disclosure beyond the annotations.

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?

Well front-loaded: what it does and its write semantics precede args, returns, and notes. It is long, and a few points are restated ('no history is kept' / 'losing the old one'), but nearly every clause adds operationally useful information for a destructive 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?

No output schema exists, and the description supplies the return shape ({'rated': True, ...}) and the caveat that scores are not echoed back. Combined with error conditions, prerequisites, and side effects, nothing essential for a correct call is missing.

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 0%, so the description must carry the load and does: date_str format (YYYY-MM-DD), the exact meal_type values, integer ranges for quality (1-5) and quantity (1-5), subdomain default, and the constraint that both scores are required in one request. Every parameter is meaningfully documented.

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 first sentence gives a specific verb+resource ('Rate the taste and portion size of a meal') and immediately distinguishes it from siblings by naming choose_meal and sign_off_meal as ordering/booking tools that do not record ratings. An agent can identify the tool's job without opening the 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 states when to use it ('Rate a meal the student actually ate'), a prerequisite ('Read `get_meals` first to confirm the slot is published'), explicit exclusions, and a remediation path ('`switch_to_student` first if one login covers several children'). Alternative tools are named with their distinct purposes.

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

rate_meal

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools