Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_subdomains

Get the list of school subdomains available to your account, with per-school login status, role, and active school. Use it to discover accessible schools and determine which require login or 2FA.

Instructions

List the school subdomains available to the logged-in account and the server's session status per school, plus overall login state. Read-only.

Args: (none)

Returns: dict with: - subdomains: list of school subdomains available to the account. For a logged-in parent account this is live-discovered (via edupage-api's get_subdomains, read from the profile page) and includes schools with no session yet; it is limited to EDUPAGE_SUBDOMAINS when that is set (allowlist), otherwise every accessible school is listed. For student/teacher accounts or when not logged in it falls back to the configured / current sessions. - schools: per subdomain {subdomain, logged_in, role (student/parent/teacher), user_id, two_factor_pending, active}. When EDUPAGE_SUBDOMAINS is set it contains only the in-scope schools (sessions for unconfigured schools are never listed). - active_subdomain: the school used by tools without an explicit subdomain argument. - failed_logins: subdomain → error for login attempts that failed or are blocked (e.g. pending 2FA at startup). - env_*_set: whether EDUPAGE_USERNAME / EDUPAGE_PASSWORD / EDUPAGE_SUBDOMAINS are configured.

Notes: - Use this instead of the former auth_status / user_id tools. - To connect to a discovered subdomain that has no session yet, pass it to login_all. - A school with two_factor_pending: True needs two_factor_finish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It explicitly declares 'Read-only.' and thoroughly details return structure, edge cases (parent vs student/teacher, allowlist behavior), failed logins, and environment variable flags. This is transparent and goes beyond the basics.

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?

Although lengthy, the description is well-structured with clear sections (Purpose, Args, Returns, Notes) and front-loads the core purpose. Every sentence adds value, covering complex return semantics and usage notes without redundancy. The detail is justified given the tool's rich output.

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?

With no output schema, the description fully explains the return values and their nuances, including conditional behavior, environment variables, and integration with sibling tools. It covers all information an agent needs to correctly interpret results and decide next actions.

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?

The tool has zero parameters, so there is nothing for the description to clarify beyond the schema (which is trivially 100% covered). Per instructions, a baseline of 4 is appropriate when there are no parameters, and the description does not need to add parameter-specific meaning.

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?

The description clearly states the tool's purpose: 'List the school subdomains available to the logged-in account and the server's session status per school, plus overall login state.' It specifies a distinct verb and resource, and differentiates from siblings by noting it replaces the former auth_status/user_id tools. This makes its purpose unambiguous.

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 description explicitly tells when to use it ('Use this instead of the former auth_status / user_id tools') and provides actionable follow-up steps: passing discovered subdomains to login_all and handling two_factor_pending with two_factor_finish. This is clear contextual guidance that distinguishes it from alternatives.

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