Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_my_timetable

Read-onlyIdempotent

Fetch your timetable for a given date to view scheduled lessons; omit the date to get today's schedule.

Instructions

Get the timetable for the logged-in user on a date. Read-only.

Args: date_str: YYYY-MM-DD (default today). subdomain: School to query (defaults to the active subdomain).

Returns: dict: {'date', 'subdomain', 'lessons': [serialized lessons]}.

Notes: - For another student use get_student_timetable (by name/id); for a teacher/class/room on a date or a range use get_timetable. - Next week for yourself: get_next_week_timetable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
date_strNo
subdomainNo

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description's 'Read-only' is redundant with those annotations, though it adds useful default behavior ('default today', 'defaults to the active subdomain') and a return structure. With annotations carrying the safety profile, the added behavioral context is modest.

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?

The description is front-loaded with the core action and then uses clear Args/Returns/Notes sections. It is appropriately sized for a tool with two optional parameters and three sibling alternatives, and every section carries useful 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?

The description supplies the return dict structure despite no output schema, documents both optional parameters, and routes to all relevant sibling tools. Combined with annotations covering safety and openness, an agent has everything needed to call this tool correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It documents both parameters: date_str as YYYY-MM-DD defaulting to today, and subdomain as the school to query defaulting to the active subdomain. It covers format and default meaning but does not describe valid subdomain values or edge cases.

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 the timetable for the logged-in user on a date') and explicitly distinguishes the tool from its siblings by scope. An agent can identify exactly which timetable variant this is 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?

The Notes section explicitly names alternatives and the conditions that select them: another student → get_student_timetable, teacher/class/room or date range → get_timetable, next week for yourself → get_next_week_timetable. Nothing is left to inference.

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