Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_student_timetable

Read-onlyIdempotent

Retrieve a student's daily timetable by name or person_id, optionally across multiple schools or for a specific date. Use it to check classes and lessons for any student.

Instructions

Get a student's timetable by first/last name OR person_id. Read-only. Without a subdomain, searches every school in the discovery scope (the configured EDUPAGE_SUBDOMAINS, or all logged-in schools when unset) and returns one result per school where the student is found — so a student attending multiple schools yields separate per-school timetables.

Args: name: Student's first/last/full name. student_id: person_id (preferred — unambiguous, see find_student). date_str: YYYY-MM-DD (default today). subdomain: Restrict to one school (default: all logged-in schools).

Returns: dict: {'results': [{student, student_id, class_id, date, subdomain, lessons}]}; with a query/matched_schools summary when more than one school is searched.

Notes: - If logged in as a parent this resolves the child agent-side and queries their timetable directly (no session switching). For your own timetable use get_my_timetable. - Use the student_id from find_student / get_my_students for unambiguous lookups.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
date_strNo
subdomainNo
student_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.6.0
    • addedInput schema / properties / date_str / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / date_str / type
      Removed value: -"string"
    • 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"
  2. First observedv0.4.6

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds material context beyond that: multi-school search scope, one result per school for multi-school students, the query/matched_schools summary, parent child-resolution without session switching, and subdomain defaulting to all logged-in schools.

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 purpose and scoping caveat, and the Args/Returns/Notes structure aids scanning. It is on the long side and some notes restate preference for student_id already covered in Args, but each block still carries information.

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 compensates by describing the return dict shape and the multi-school summary variant. With no required params, the zero-parameter case is handled by documenting optional-key defaults, leaving no gap for correct invocation.

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 it does: name formats, student_id as person_id with a cross-reference, date_str as YYYY-MM-DD with a today default, and subdomain semantics. Every parameter is disambiguated.

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 ('Get a student's timetable') plus the two lookup keys, and explicitly distinguishes itself from get_my_timetable and get_timetable by naming the alternative for one's own schedule. An agent can route correctly 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?

Gives explicit when-to-use rules: prefer student_id (unambiguous, sourced from find_student/get_my_students), use get_my_timetable for your own timetable, and explanatory behavior for parent logins. Alternatives and edge conditions are spelled out rather than implied.

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