syllabus-calendar-mcp

Merge course calendars

merge_calendars

Instructions

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

Input Schema

Name	Required	Description
`calendars`	Yes	The calendars to merge, each with the calendar text and an optional name.
`output_path`	No	Optional file path for the .ics file. The folder must already exist because folders are not created. Leave it out to get the calendar text back instead.
`calendar_name`	No	Name for the merged calendar. Defaults to "Merged course calendar".

Output Schema

Name	Required	Description
`ics`	Yes	The merged calendar as text, with CRLF line breaks.
`valid`	Yes	True when the merged calendar passed the built in checks.
`errors`	Yes	Problems found by the checks. Empty when the calendar is valid.
`conflicts`	Yes	Every pair of timed events that overlaps, in date order.
`event_count`	Yes	How many events the merged calendar holds, after repeated UIDs are dropped.
`output_path`	Yes	The file path the calendar was written to, or null when no path was passed.
`calendar_count`	Yes	How many calendars were passed in.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Nov 3, 2026

changedInput schema / properties / output_path / description

Previous value: -"Optional file path. When it is passed, the calendar is written there as a .ics file."New value: +"Optional file path for the .ics file. The folder must already exist because folders are not created. Leave it out to get the calendar text back instead."

First observedv0.1.0Oct 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond annotations, the description discloses the dedupe rule (same UID kept once), that weekly/daily recurrences are expanded for conflict checking, and that output_path writes a file whose folder must pre-exist. That also explains why readOnlyHint is false, since a file may be written. It leaves overlap semantics and timezone handling unaddressed.

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?

Purpose is front-loaded in the first sentence, followed by inputs, then behavioral rules, then an example. It is compact and well ordered, with only slight redundancy between the inputs sentence and the schema.

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?

An output schema exists, so return values need not be described, and the description covers the key non-obvious behaviors (UID dedupe, recurrence expansion, output file handling). What is missing is how overlap is determined and any timezone or calendar-name conflict rules, which matter for a merge tool.

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 the schema already documents calendars, output_path, and calendar_name, including the folder-must-exist constraint and default name. The description mostly restates those parameters rather than adding new meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource: merge course calendars and list timed events that overlap. That is precise enough to distinguish it from build_ics and expand_recurring_classes, but the description never names those siblings or states the boundary explicitly.

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 example prompt ("Merge my three course calendars and tell me which classes conflict") gives a concrete usage context, and the description makes clear the intended scenario is checking course conflicts. There are no explicit when-not conditions or named alternatives to route against.

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

Deploy Server