Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

switch_to_student

Idempotent

Set the active session to a child's student account (parent accounts only) so later EduPage actions use that student's data. Revert by switching back to the parent account.

Instructions

Switch the session to a student account (parent accounts only). Writes: changes which account subsequent tools operate as.

Args: student_id: person_id of the child (from get_my_students). name: first/last/full name of the child, used when student_id is omitted. subdomain: School to query (defaults to the active subdomain).

Returns: dict: {'switched_to_student': , 'user_id': ...}.

Notes: - Revert with switch_to_parent. Prefer the stateless get_student_timetable (name/student_id) over switching when you only need a timetable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
subdomainNo
student_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • 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.6/5.0
Behavior4/5

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

Description discloses the key behavioral trait — this is a stateful write that changes which account subsequent tools operate as — plus the revert path. It also explains the student_id vs name fallback and the subdomain default. Annotations (idempotentHint=true, destructiveHint=false) already cover safety, so remaining gaps are minor.

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 purpose in the first clause, then Args/Returns/Notes sections. Slightly verbose with the Returns dict, but the structure is clear and every section earns its place for a stateful 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?

Given no output schema, the description supplies the return shape, the stateful side effect, the sibling alternatives, the revert path, and parameter fallback logic. An agent has everything needed to call this correctly without opening other tools' docs.

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 coverage is 0%, so the description must carry the load — and it does, explaining student_id (person_id from get_my_students), name as fallback when student_id is omitted, and subdomain defaulting to the active subdomain. Uses of name (first/last/full) are clarified as the child's name, though the accepted string format isn't fully pinned down.

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 action (switch session to a student account) with the precondition (parent accounts only). Distinguishes itself from siblings like get_student_timetable and switch_to_parent by clarifying it changes the operating account context for subsequent tools.

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 says when to use it (parent accounts switching to a child) and when not to (prefer stateless get_student_timetable for timetable-only needs), and names switch_to_parent as the revert. This is exactly the routing guidance an agent needs.

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