Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_timeline

Read-onlyIdempotent

Fetch EduPage timeline notifications by category—recent, history, homework, assignments, absences, events, or news—to review school updates without changing data.

Instructions

Get EduPage timeline notifications, filtered by category. Read-only.

Args: category: Which event types to return: - 'recent' (default) — all currently visible notifications (homework, tests, messages, grades, events...). - 'history' — all notifications since date_from (incl. older ones). - 'homework' — homework assignments (formerly get_homework). - 'assignments' — homework, tests, exams and projects (formerly get_assignments). - 'absences' — absence records (formerly get_absences). - 'events' — upcoming events: trips, excursions, meetings, holidays... (formerly get_upcoming_events). - 'news' — school news (formerly get_news). date_from: YYYY-MM-DD. Only meaningful for category='history'. subdomain: School to query (defaults to the active subdomain).

Returns: dict with subdomain and the matching notifications, e.g. {'subdomain': ..., 'notifications': [...]} (key is the category name).

Notes: - Categories are derived from timeline notifications; a school that doesn't publish a given event type returns an empty list. - For a whole-day report (timetable, substitutions, meals, homework, events, news, grades) prefer get_day_summary — one call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNorecent
date_fromNo
subdomainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • addedInput schema / properties / category / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / category / type
      Removed value: -"string"
    • addedInput schema / properties / date_from / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / date_from / type
      Removed value: -"string"
    • addedInput schema / properties / subdomain / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / subdomain / type
      Removed value: -"string"
  2. Addedv0.5.0

TDQS

A4.8/5.0
Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and the description redundantly restates 'Read-only'. The added value is real behavioral context: the return shape, the keying by category name, and the fact that a school not publishing an event type returns an empty list rather than erroring. It stops short of pagination or limit behavior, so a 4 rather than a 5.

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?

Front-loaded one-line summary, then Args/Returns/Notes blocks that each earn their place. Length is justified by the seven category values, and no sentence is filler.

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?

Despite no output schema, the description supplies the return shape and key, the empty-list edge case, per-category semantics, the date_from constraint, the subdomain default, and the sibling alternative. An agent has everything needed to call this correctly.

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 description coverage is 0%, so the description carries the full burden and does: it documents the full enumerated set of category values with defaults, specifies date_from's YYYY-MM-DD format and its conditional relevance, and states subdomain defaults to the active subdomain. Nothing in the schema is left unexplained.

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+resource ('Get EduPage timeline notifications, filtered by category') and immediately differentiates the scope from siblings by naming get_day_summary as the whole-day alternative. An agent can distinguish this from get_timetable, get_grades, and the category-specific former tools 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?

Explicitly enumerates every category value with its meaning, marks 'recent' as the default, ties date_from to category='history' only, and gives a named alternative (get_day_summary) with the condition that selects it. When/when-not and alternatives are all present.

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

Deploy Server

Other Tools