syllabus-calendar-mcp

Expand recurring classes

expand_recurring_classes

Read-only

Generate all meeting dates for a recurring class between start and end dates while skipping holidays and reading weeks, then list skipped dates and reasons.

Instructions

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."

Input Schema

Name	Required	Description
`title`	No	Title for the calendar event. Defaults to the course name plus class.
`course`	Yes	Course name or code, such as BIO 101.
`end_date`	Yes	Last date of the term as YYYY-MM-DD.
`end_time`	No	Class end time as HH:MM or 2:30 PM. It must be after start_time.
`holidays`	No	Holiday dates or ranges, such as "2026-10-12" or "2026-10-12 to 2026-10-16".
`location`	No	Room or place.
`weekdays`	Yes	Days the class meets, as names or codes, such as "Tuesday", "Tue" or "TU".
`start_date`	Yes	First date of the term as YYYY-MM-DD.
`start_time`	Yes	Class start time as HH:MM or 2:30 PM.
`reading_weeks`	No	Reading week dates or ranges, such as "2026-10-12 to 2026-10-16".

Output Schema

Name	Required	Description
`title`	Yes	Title used for the calendar event.
`course`	Yes	Course name or code.
`skipped`	Yes	Dates that were skipped, with the reason.
`end_date`	Yes	Last date of the term.
`end_time`	Yes	Class end time, or null when none was passed.
`location`	Yes	Room or place, or null when none was passed.
`meetings`	Yes	Every class meeting, in date order.
`weekdays`	Yes	The weekdays as two letter codes.
`next_step`	Yes	Suggested next tool call for turning the class meetings into a calendar.
`start_date`	Yes	First date of the term.
`start_time`	Yes	Class start time.
`candidate_count`	Yes	How many dates matched the weekdays before holidays and reading weeks were removed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond that: it returns every meeting date plus skipped dates with reasons, and terminates with a next-step hint. It does not mention output ordering/format limits, keeping it short of a 5.

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 the core action, then inputs, then return behavior, then the example prompt. The enumerated input list partly duplicates the schema, but the example prompt earns its place by showing the intended invocation shape. Slightly verbose but well-ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with an output schema, the description covers purpose, input shapes, return content (meeting dates, skipped dates with reasons), and next-step routing. What remains unstated — e.g. how dates are ordered or how conflicts between holidays and reading weeks are resolved — is modest given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including holidays and reading_weeks is already documented with formats and examples. The description's input list largely restates the schema (weekdays names or codes, date formats), adding no new semantics. Baseline 3 applies.

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: 'Generate the meeting dates for a recurring class between two dates, and skip holidays and reading weeks.' This is clearly distinguishable from siblings like extract_schedule_events (which presumably reads a schedule) and names build_ics as the downstream tool, so an agent can route correctly.

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?

Usage context is clear from the example prompt ('My biology class meets Tuesday and Thursday... Skip the reading week') and the next-step hint toward build_ics. However, it never explicitly says when NOT to use this versus extract_schedule_events or merge_calendars, leaving the sibling boundary to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server