Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

login_all

Idempotent

Authenticate to multiple EduPage schools in one call with comma-separated subdomains and credentials, establishing a session for each.

Instructions

Log in to one or more schools in a single call. Writes: establishes (or replaces) the server-side session for each subdomain.

Args: subdomains: Comma-separated school subdomains, e.g. 'school1,school2'. Falls back to EDUPAGE_SUBDOMAINS. usernames: Comma-separated usernames, one per school (or a single one). Falls back to EDUPAGE_USERNAME. passwords: Comma-separated passwords, one per school (or a single one). Falls back to EDUPAGE_PASSWORD.

Returns: dict: {'results': [{subdomain, ok, user_id, role, two_factor_required}], 'active_subdomain': ...}. A failed school is reported per-entry with its error.

Notes: - Add schools one at a time with login. - When EDUPAGE_SUBDOMAINS is set it is a strict allowlist: schools outside it are refused per-entry without creating a session. - Finish any pending 2FA with two_factor_finish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
passwordsNo
usernamesNo
subdomainsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • addedInput schema / properties / passwords / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / passwords / type
      Removed value: -"string"
    • addedInput schema / properties / subdomains / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / subdomains / type
      Removed value: -"string"
    • addedInput schema / properties / usernames / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / usernames / type
      Removed value: -"string"
  2. First observedv0.4.6

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), yet the description adds real behavioral context beyond them: it discloses that sessions are established OR REPLACED per subdomain, that EDUPAGE_SUBDOMAINS acts as a strict allowlist with per-entry refusal, and that failures are reported per-entry rather than aborting the call.

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 a one-sentence purpose, then organized into Args/Returns/Notes sections where each block is functional. It is somewhat long, but the length is driven by needed fallback and failure semantics rather than padding.

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 supplies the return shape ({'results': [{subdomain, ok, user_id, role, two_factor_required}], 'active_subdomain': ...}) plus per-entry error handling, allowlist behavior, and required follow-up calls. Nothing an agent needs in order to invoke or interpret this tool is missing.

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 so thoroughly: it documents the comma-separated format for all three params, the positional alignment rule ('one per school (or a single one)'), and the environment-variable fallback for each (EDUPAGE_SUBDOMAINS/USERNAME/PASSWORD).

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 ('Log in to one or more schools in a single call') and immediately declares the write nature of the operation. The batch/multi-school scope is explicit, which is what separates it from the single-school sibling `login`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The Notes route the agent to the right alternatives: `login` for adding schools one at a time and `two_factor_finish` for completing pending 2FA. However, it never states the inverse condition explicitly (e.g. 'prefer login when only one school is needed'), so the routing is implied rather than fully spelled out.

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