syllabus-calendar-mcp

Extract schedule events

extract_schedule_events

Read-only

Converts pasted syllabus text into dated events, assigning titles, types, dates, and optional times, while returning undated lines separately for review.

Instructions

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

Input Schema

Name	Required	Description
`text`	Yes	The pasted syllabus or course schedule. Put one event on each line, with a date on the line.
`year`	No	The year to use when a date has no year. Defaults to the current year.
`course`	No	Course name or code to put on every event, such as BIO 101.

Output Schema

Name	Required	Description
`year`	Yes	The year used for dates that did not name one.
`count`	Yes	How many events were found.
`events`	Yes	Every dated event that was found, in date order.
`next_step`	Yes	Suggested next tool call for turning the events into a calendar.
`undated_lines`	Yes	Lines that had no date, kept in the order they appeared so they can be fixed.

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 declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavior: undated lines are surfaced in undated_lines rather than silently dropped, events are classified into seven types, and the response ends with a next-step hint. That is meaningful disclosure of output behavior and failure handling beyond the safety hints.

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 mechanics and a concrete example prompt that anchors the format. Slight redundancy in re-listing the three inputs, which the schema already documents, keeps it from being fully tight.

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?

With an output schema present and annotations covering the safety profile, the description fills the remaining gaps well: the line-per-event parsing contract, the event taxonomy, what happens to undated lines, and the downstream build_ics step. Adequate for an agent to call it confidently; only the recurring-class handoff is unaddressed.

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 baseline is 3. The description restates all three parameters ('text', 'course', 'year') but largely paraphrases the schema text, adding only the framing that course goes 'on every event' and year resolves dateless dates -- no syntax or edge-case detail beyond the schema.

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 -- 'Extract dated events from pasted syllabus text' -- and immediately explains the one-event-per-line mapping rule. None of the siblings (expand_recurring_classes, build_ics, merge_calendars) do parsing, so the boundary is unambiguous even without naming them.

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 input precondition is explicit (pasted syllabus/course schedule text, one event per line), and the description routes the agent onward to build_ics when events should become a calendar. It does not address whether recurring class lines should instead go to expand_recurring_classes, which is the one plausible ambiguity among siblings.

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

Deploy Server