syllabus-calendar-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| extract_schedule_eventsA | Extract dated events from pasted syllabus text. Each line that names a date becomes one event, with a title, a type, a date and optional times. Inputs: text (the pasted syllabus or course schedule, one event per line), course (a course name or code to put on every event) and year (the year to use when a date has no year). Titles are read from the words around the date, and each event is marked as an assignment, exam, quiz, lab, reading, class or other. Any line that has no date is returned in undated_lines instead of being dropped silently. The answer ends with a next step hint that points to build_ics when the events should become a calendar. Example prompt: "Turn this syllabus into calendar events: Assignment 1 due Sep 15, Midterm exam October 20 at 10:00." |
| expand_recurring_classesA | Generate the meeting dates for a recurring class between two dates, and skip holidays and reading weeks. Inputs: course, weekdays (day names or codes such as Tuesday or TU), start_date, end_date, start_time, optional end_time, optional location, holidays (single dates or ranges) and reading_weeks (single dates or ranges). Returns every meeting date plus the dates that were skipped and why. The answer ends with a next step hint that points to build_ics when the class should become a calendar. Example prompt: "My biology class meets Tuesday and Thursday from Sep 8 to Dec 10, 2026 at 10:00. Skip the reading week of Oct 12 to Oct 16." |
| build_icsA | Build a valid .ics calendar file from dated events and recurring classes, with reminders. Inputs: events (each with title, date, optional start_time, end_time, type, course, location and notes), classes (each with course, weekdays, start_date, end_date, start_time and optional end_time, location, holidays and reading_weeks), reminders_minutes (whole minutes before each event, default 60), calendar_name and optional output_path. Each class becomes one weekly recurring event with holidays and reading weeks removed. The tool checks the file before returning it. Example prompt: "Make an .ics file for my course with a reminder one day before each assignment." |
| merge_calendarsA | Merge several course calendars into one and list timed events that overlap. Inputs: calendars (each with an optional name and an ics string), optional calendar_name and optional output_path. Events with the same UID are kept once. Weekly and daily recurring events are expanded when conflicts are checked. Example prompt: "Merge my three course calendars and tell me which classes conflict." |
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 4 tools
The four tools represent distinct pipeline stages: extraction, recurrence expansion, ICS generation, and merging. The only mild overlap is between expand_recurring_classes and build_ics, since build_ics also accepts recurring class definitions and expands them internally, but the descriptions make the output distinction clear.
All names use a consistent snake_case verb_noun pattern: extract_schedule_events, expand_recurring_classes, build_ics, and merge_calendars. The convention is predictable and readable throughout.
Four tools are well-scoped for a syllabus-to-calendar workflow, with each tool covering a meaningful step. There are no redundant or trivial tools.
The surface covers the core lifecycle: extracting events, expanding recurring classes, building a checked .ics file, and merging calendars. Minor gaps exist around post-generation editing or standalone calendar validation, but the main workflow is complete.