EduPage MCP Server

get_day_summary

Read-onlyIdempotent

Generate a daily school report for a date, including timetable, grades, homework, meals, and absences, for a student or all children.

Instructions

One-call daily school report for a date (default today): timetable, substitutions, missing teachers, grades received that day, meals, homework, assignments, absences, news, events, and timeline notifications.

Composes the individual section tools so you don't need to fire 8-10 calls to answer "what happened yesterday at school" or "what's coming tomorrow".

If name/student_id is provided: report for that specific student (found across all schools unless subdomain scopes it).
If omitted: discovery-first — for a parent this returns a lightweight per-school index of the account's children (no per-child section fetching), so you can then call per child with name/student_id. Set full=True to instead build the full report for every child.
If omitted and logged in as student/teacher: report on the logged-in account. Every section is isolated — a failure in one section yields {"ok": false, "error": ...} without failing the report.

Args: date_str: YYYY-MM-DD to report on (default today). name: Student to report for, by first/last/full name. Ambiguous names surface every candidate instead of guessing. Ignored when student_id is given; see find_student to resolve an id first. student_id: person_id of the student (preferred, unambiguous). Found across all schools unless subdomain scopes the lookup. subdomain: School to report on (defaults to the active subdomain). full: When no name/student_id is given and the account is a parent, build the full report for every child instead of returning the lightweight per-school index. Costs one section sweep per child.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`full`	No
`name`	No
`date_str`	No
`subdomain`	No
`student_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.6.0Oct 2, 2026

addedInput schema / properties / date_str / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / date_str / type
```
Removed value: -"string"
```

addedInput schema / properties / full / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / full / type
```
Removed value: -"boolean"
```

addedInput schema / properties / name / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / name / type
```
Removed value: -"string"
```

addedInput schema / properties / student_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / student_id / type
```
Removed value: -"string"
```

addedInput schema / properties / subdomain / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / subdomain / type
```
Removed value: -"string"
```

Changed1 schema field changedv0.4.10Sep 12, 2026

addedInput schema / properties / full

Added value: +{
+  "default": false,
+  "title": "Full",
+  "type": "boolean"
+}

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 carry readOnly/idempotent/non-destructive/openWorld, so the description adds meaningfully beyond them: it discloses that every section is isolated and a failure yields {"ok": false, "error": ...} without failing the whole report, that ambiguous names surface all candidates rather than guessing, and that full=True costs one section sweep per child. These are non-obvious behavioral traits well past what the annotations convey.

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?

Front-loaded with the core promise, then well-sectioned bullets. It is somewhat long, with the discovery-first logic restated in both the body and the args list, but given five undocumented parameters and a complex composite operation the length is largely earned.

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 complex composite tool with no output schema and 0% schema coverage, the description supplies parameter meaning, routing rules, partial-failure semantics, and cross-school scoping. No output schema exists so return-value detail is not owed, and nothing an agent needs to invoke it correctly 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?

With 0% schema description coverage the description must carry the full burden, and it does: date_str format (YYYY-MM-DD, default today), name (first/last/full, ambiguity behavior, ignored when student_id is set), student_id (preferred person_id, cross-school unless scoped), subdomain (default active), and full (parent-only behavior and cost). All five parameters get semantics the bare schema lacks.

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?

States a specific verb and resource ('One-call daily school report for a date') and enumerates exactly what it aggregates (timetable, grades, meals, absences, events). It also distinguishes itself from siblings by explaining it composes the individual section tools like get_grades and get_meals, so an agent can tell it apart without opening any 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?

Gives explicit when-to-use framing ('what happened yesterday at school' / 'what's coming tomorrow') and the alternative it replaces ('you don't need to fire 8-10 calls'). It then spells out the conditional routing: name/student_id present → specific student; omitted → discovery-first index for parents; full=True for the full multi-child report; omitted as student/teacher → logged-in account.

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

get_day_summary

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools