schoolpass-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCHOOLPASS_EMAIL | Yes | Your SchoolPass parent account email. | |
| SCHOOLPASS_API_HOST | No | Regional API host override (default busapi-east16-ss.school-pass.net). | |
| SCHOOLPASS_PASSWORD | Yes | Your SchoolPass password. | |
| SCHOOLPASS_SCHOOL_CODE | Yes | The numeric school id (the AppCode / appCode value; e.g. 1183). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| schoolpass_healthcheckA | Check SchoolPass connectivity and authentication. Reports whether the regional API host is reachable (an unauthenticated version probe) and, separately, whether the configured credentials log in — so a network problem is distinguishable from a bad password or school code. |
| schoolpass_whoamiA | Return the parent account this server is signed in as: member id, user type, and name. Runs the login bootstrap if it has not run yet. |
| schoolpass_list_studentsA | List the students linked to the parent account: name, grade, home dismissal location, aftercare flag, and per-student details. Defaults to the signed-in parent. |
| schoolpass_get_profileB | Get the parent account profile (contact details and account settings) for the signed-in parent. |
| schoolpass_list_driversA | List the authorized pickup drivers registered on the parent account. Pass include_carpool: true to also get the carpools each belongs to — those records describe OTHER families, so on the default compact view their contact and vehicle fields are dropped (view "full" keeps them). |
| schoolpass_get_calendarA | Get a student’s arrival & dismissal calendar over a date range — the per-day default and any changes. Requires a student id (from schoolpass_list_students). Defaults to today through 14 days out. |
| schoolpass_list_pickup_changesA | List pickup / dismissal changes for a student on a given date (defaults to today) — early pickups, late arrivals, carpool moves, and the like. Requires a student id. |
| schoolpass_list_dismissal_locationsA | List the school’s dismissal locations (car line, bus, aftercare, walkers, etc.) with their ids — the vocabulary a dismissal change refers to. |
| schoolpass_get_school_infoA | Get basic school info and per-school configuration (features enabled, dismissal windows, etc.) for the configured school. |
| schoolpass_submit_dismissal_changeA | Submit a dismissal/arrival change for a student on a single date — send them to a different dismissal location or carpool, mark early dismissal / late arrival / absent, etc. CONFIRM-GATED: a client that supports MCP elicitation gets a confirmation prompt; otherwise the first call makes NO change and returns a preview (the child by name, the date, the change, the exact request) plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The token is bound to the previewed arguments and to the day as it was read, so a day that changed in between is refused with a fresh preview. Once confirmed it submits and then re-reads the calendar to show the change landed (verified:true); if the re-read fails or does not show it yet the result is verified:false — the change WAS submitted, so do not resubmit; re-read the calendar instead. Get student_id from schoolpass_list_students and move_to_id from schoolpass_list_dismissal_locations (a dismissal location id) or the student calendar (a carpool moveToId). |
| schoolpass_cancel_dismissal_changeA | Cancel a previously-submitted dismissal/arrival change for a student on a date, returning that date to its default. CONFIRM-GATED: a client that supports MCP elicitation gets a confirmation prompt; otherwise the first call makes NO change and returns a preview (the child by name, the date, the change, the exact request) plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The token is bound to the previewed arguments and to the day as it was read, so a day that changed in between is refused with a fresh preview. Once confirmed it deletes the change and re-reads the calendar to confirm the day is back to default. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools target distinct resources/actions, but there is mild overlap between schoolpass_get_profile and schoolpass_whoami (both describe the signed-in parent) and between schoolpass_get_calendar and schoolpass_list_pickup_changes (both surface dismissal changes). The descriptions distinguish them well enough that misselection is unlikely, but they aren't perfectly orthogonal.
All tools share the schoolpass_ prefix and follow a clean verb_noun pattern (get_, list_, submit_, cancel_). The exceptions are schoolpass_healthcheck and schoolpass_whoami, which are conventional but don't match the verb_noun shape, so consistency is high but not perfect.
11 tools is well within the sweet spot for a domain-specific server. Each tool maps to a clear capability (school info, auth check, students, drivers, calendar, changes, profile, identity) and none feel redundant or padded.
The set covers the full core lifecycle: identity/auth check, discovery of students/locations/drivers, reading the calendar and changes, and submit/cancel of dismissal changes with verification. Minor gaps exist (e.g. no tool to modify driver/carpool registrations or update profile settings), but the primary parent workflows are complete.