Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SchoolMessenger MCP Draft an absence for Emma tomorrow with the reason 'doctor appointment'."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Absence-only MCP server for SchoolMessenger SafeArrival.
This server is intentionally narrow. It can list attendance-enabled students, list absence types/reasons, list existing absences, draft an absence, submit a previously drafted absence, draft an absence cancellation, and cancel a previously drafted cancellation only when the caller provides the exact confirmation phrase returned by the draft tool.
Use environment variables:
export SCHOOLMESSENGER_REGION=ca
export SCHOOLMESSENGER_USERNAME='parent@example.com'
export SCHOOLMESSENGER_PASSWORD='...'
schoolmessenger-mcpOr use the existing local credentials file:
export SCHOOLMESSENGER_REGION=ca
export SCHOOLMESSENGER_CREDS_FILE=~/.config/schoolmessenger.ca/creds.yml
export SCHOOLMESSENGER_ACCOUNT=default
schoolmessenger-mcpCredential YAML shape:
default:
username: parent@example.com
password: passwordDo not commit credentials.
Related MCP server: MCP-Server-CollageAI
list_students
list_absence_options
list_absences
draft_absence
submit_absence
draft_cancel_absence
cancel_absence
draft_absence performs local validation and returns a human-readable confirmation phrase.
submit_absence refuses to call SchoolMessenger unless the phrase exactly matches a draft stored
in the current MCP process.
draft_cancel_absence looks up an existing absence, returns a human-readable cancellation summary,
and provides a CANCEL ABSENCE <draft_id> confirmation phrase. cancel_absence refuses to call
SchoolMessenger unless that phrase exactly matches a cancellation draft stored in the current MCP
process.
The server never logs OAuth tokens or passwords.
{
"mcpServers": {
"schoolmessenger": {
"command": "python3",
"args": ["-m", "schoolmessenger_mcp.server"],
"env": {
"SCHOOLMESSENGER_REGION": "ca",
"SCHOOLMESSENGER_CREDS_FILE": "~/.config/schoolmessenger.ca/creds.yml",
"SCHOOLMESSENGER_ACCOUNT": "default"
}
}
}
}Discovery notes are in docs/api.md.
Cancel a previously drafted absence cancellation after exact confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| draft_id | Yes | ||
| confirmation_phrase | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only mentions 'exact confirmation' which implies a guarded action, but doesn't explain side effects, irreversibility, or what happens on success/failure. The wording is potentially misleading about whether it cancels a draft or executes a cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but its brevity sacrifices clarity. It is not well-structured because the meaning is ambiguous; conciseness does not compensate for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, an output schema, and several siblings, yet the description fails to place it in the workflow (draft_cancel_absence → cancel_absence). It doesn't explain the purpose of the confirmation phrase or the output format. The context is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of draft_id or confirmation_phrase. It only hints at 'confirmation' without specifying what the phrase should be or how it is validated. The agent has no information to fill these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Cancel' is specific, but the resource is ambiguous: 'a previously drafted absence cancellation' could mean undoing a draft or finalizing a cancellation. It doesn't clearly distinguish from sibling 'draft_cancel_absence'. The phrase 'after exact confirmation' hints at a confirmation step but doesn't clarify the overall action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like draft_cancel_absence or submit_absence. It doesn't state that this tool is the final confirmation step in a two-stage process, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft an absence and return the confirmation phrase required for submit_absence.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| reason | Yes | ||
| comment | No | ||
| in_time | No | ||
| student | No | ||
| end_date | No | ||
| out_time | No | ||
| start_date | No | ||
| absence_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state the output (a confirmation phrase), but it does not disclose whether drafting persists state, whether it is reversible, or whether any side effects occur before submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and immediately adds the key behavioral detail about the returned confirmation phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and no parameter descriptions, the description is insufficient for correct invocation. It identifies the tool's role and output but leaves required inputs, valid absence types, and draft state semantics unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no guidance about the 9 parameters, including the two required ones (absence_type and reason). The agent is left to infer what values are valid and how parameters like date, student, and absence_type relate to the draft.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Draft an absence') and clarifies its distinct role by noting it returns the confirmation phrase required for submit_absence. This clearly separates it from siblings like submit_absence and draft_cancel_absence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'required for submit_absence' implies this tool is a prerequisite step before submitting an absence, providing useful sequencing context. However, it does not explicitly state when not to use it or mention alternatives like draft_cancel_absence or list_absence_options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft cancellation of an existing absence and return the required confirmation phrase.
| Name | Required | Description | Default |
|---|---|---|---|
| to_date | No | ||
| from_date | No | ||
| absence_id | Yes | ||
| customer_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It reveals the key behaviors: it drafts rather than cancels, and returns a confirmation phrase. However, it omits details like side effects (or their absence), error conditions, or authentication requirements. The word 'draft' implies non-destructive, but it's not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It efficiently states the action and outcome, making it easy to scan. There is no redundant phrasing or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return values), the description is insufficient for a tool with four parameters and no annotations. It fails to explain parameter semantics, does not outline the cancellation workflow with sibling tools, and omits any usage context. An agent would struggle to call this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description fails to mention any of the four parameters (absence_id, from_date, to_date, customer_id) or their purpose, so it adds zero value beyond the schema's bare type declarations. An agent has to guess the meaning and usage of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Draft cancellation'), the resource ('existing absence'), and the output ('return the required confirmation phrase'). It differentiates from 'cancel_absence' (which likely performs the cancellation) and 'draft_absence' (which drafts a new absence) by focusing on the cancellation draft flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. It doesn't mention that this is a prerequisite for 'cancel_absence' or that the confirmation phrase must be used there. There's no explicit when/when-not guidance, leaving the agent to infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List absence types and reasons for a student selector or the only available student.
| Name | Required | Description | Default |
|---|---|---|---|
| student | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the basic action (listing options) without disclosing side effects, permissions, or edge cases (e.g., behavior when no student is provided or when multiple students exist). Minimal behavioral disclosure beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. It avoids unnecessary words, though it could be more structured by separating the purpose from the parameter clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and no annotations, but the description leaves ambiguity about the 'student selector' context and the meaning of 'only available student.' An output schema exists, so return details are not required, but the description should clarify the tool's exact role and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify the 'student' parameter. It implies the parameter is optional ('or the only available student') and relates to selecting options, but it doesn't explain the parameter's format, allowed values, or how it determines the result. Adds some meaning but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('absence types and reasons'), which distinguishes it from list_absences (which likely lists actual absences). However, the qualifier 'for a student selector or the only available student' is ambiguous and doesn't precisely convey the tool's role in a UI flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like list_absences or draft_absence. The phrase 'for a student selector' hints at a UI context, but it doesn't state when to choose this over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing absences for a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to_date | No | ||
| from_date | No | ||
| unexplained_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states only that the tool lists absences but does not disclose whether it includes drafts, requires specific permissions, or has any side effects. For a read operation, it fails to explicitly confirm that it is safe and non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler words. The main action is front-loaded, and the scope is stated immediately. While it is minimal, it is appropriately sized for such a simple operation and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of three parameters (including a boolean with non-obvious semantics) and no annotations, the description is incomplete. It does not explain the meaning of unexplained_only or any return-value specifics, even though an output schema exists. An agent would need to guess about the boolean's purpose and the exact nature of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the undocumented parameters. It mentions 'a date range', which roughly maps to from_date and to_date, but it gives no explanation for the unexplained_only boolean parameter. This leaves a third of the parameters without any semantic guidance beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('existing absences') with a scope ('for a date range'). It is distinct from sibling tools like draft_absence or cancel_absence, which imply creation or modification, so an agent can easily tell this is a read-only listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions or explicit conditions, such as 'use this to retrieve absences rather than to create or modify them.' The description relies entirely on the tool name and implied purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List attendance-enabled students available to the configured account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior. It discloses that the tool is read-only by the verb 'List' and specifies the filtering behaviors: only attendance-enabled students and only those available to the configured account. It does not mention response details, but the output schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that earns its place: the verb, resource, and key qualifiers are all present with zero filler. It is appropriately sized for a 0-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0-parameter schema and the presence of an output schema, the description is mostly complete. It clearly identifies what the tool returns and the account scope. The only gap is the absence of explicit guidance tying this tool to the absence-sibling flows, but the 'attendance-enabled' qualifier makes that link evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete and the description has no parameter meanings to add. The baseline for 0-parameter tools is 4, and the description contains no extraneous parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with a specific resource ('attendance-enabled students') and a clear scope ('available to the configured account'). This distinguishes it from all sibling tools, which are absence-action operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to see which students can be selected for attendance-related workflows, but it never explicitly says when to use it versus the absence-tool siblings. No exclusions or alternative routes are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a previously drafted absence after exact confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| draft_id | Yes | ||
| confirmation_phrase | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It indicates the action is a submission (a write operation) and mentions 'exact confirmation,' which suggests a safety mechanism requiring the confirmation_phrase. However, it does not disclose the consequences of submission (e.g., whether it can be undone, whether it triggers notifications, or what the output signifies).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, with no redundancy, and it is appropriately short. It states the core purpose efficiently, but it could be slightly longer to include an example of the confirmation phrase or parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and an output schema, the description is on the lighter side. It covers the basic purpose but lacks guidance on how to obtain a draft_id (e.g., via list_absences), what constitutes an 'exact confirmation,' and what the output signifies. The output schema exists but is not shown, so the description doesn't need to explain return values, but it should still provide more context around the confirmation phrase.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain the parameters, but it does not. It mentions 'draft' and 'confirmation' indirectly, but it does not explain that draft_id identifies the draft to submit or that confirmation_phrase is the exact phrase required. The description adds minimal value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit) and the resource (absence), and qualifies it as 'previously drafted' and requiring 'exact confirmation'. This distinguishes it from 'draft_absence' (creation) and 'cancel_absence' (cancellation), though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finalizing a draft, but it does not explicitly state when to use it versus alternatives like 'draft_cancel_absence' or 'cancel_absence'. The phrase 'after exact confirmation' gives context that a confirmation phrase is needed, but it lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cancel_absencedraft_absencedraft_cancel_absencelist_absence_optionslist_absenceslist_studentssubmit_absenceScored across 7 tools
The tools are mostly distinct: listing students, absence options, absences, drafting, submitting, and canceling. However, 'draft_cancel_absence' and 'cancel_absence' overlap somewhat, as both relate to cancellations, but the context (draft vs submit) helps disambiguate.
Mostly consistent verb_noun pattern (list_*, draft_*, submit_*, cancel_*). The only minor deviation is draft_cancel_absence, which is a compound verb but still understandable.
7 tools is well-scoped for a school attendance management server. Each tool serves a clear purpose in the workflow without redundancy.
The workflow covers listing options, listing existing data, drafting, submitting, and canceling (both full and drafted cancellations). This seems complete for the stated domain of managing absences.
Check shifts, time clock entries, time-off requests, swaps and availability, and manage shifts.
Manage Accelo companies, contacts, jobs, tasks, tickets and time.
Look up Momence members, class schedules, bookings and memberships, and handle front-desk actions.
Manage incidents and on-call: list/create/update incidents, who is on call, on-call overrides.