Skip to main content
Glama
AnonymousOnyx22

Study Planner MCP

by AnonymousOnyx22
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Export study plan as ICS

export_study_plan_ics
Read-only

Convert a study plan into an .ics calendar file for Google Calendar or Apple Calendar, with study sessions and exams as all-day events ready to import.

Instructions

Turn a study plan into an .ics calendar file to import into Google Calendar or Apple Calendar. It builds the same plan as build_study_plan, with the same hours_per_weekday if you set one, and answers with the whole file, so save the answer as plan.ics and open it. Every study session becomes an all day event that shows as free, with the topics of the session in its description when the exam has topics, and every exam becomes an all day event that shows as busy unless include_exams is false. Add reviews with the day you first studied each one to add Review: all day events to the calendar. Dates can be plain text, like Dec 12 or in 3 weeks. Example prompt: "Export my plan for a networking exam on 2026-12-12, 6 hours, starting 2026-12-07, as an ICS file."

Input Schema

NameRequiredDescriptionDefault
examsYesExams with name, date, optional hours needed and optional topics with their own hours.
reviewsNoTopics you are reviewing, with the day you first studied each one.
days_offNoWeekdays with no studying, like ["sun"].
start_dateNoFirst day to study. Defaults to today. Use 2026-12-12, or plain text like Dec 12, next Friday or in 3 weeks.
hours_per_dayNoStudy hours available on a study day.
include_examsNoAlso add an all day event on each exam day. Set false for study sessions only.
intervals_daysNoDays after the first study to review.
hours_per_weekdayNoStudy hours for each weekday, like [{day: "mon", hours: 2}, {day: "sat", hours: 6}]. Weekdays you leave out use hours_per_day, a weekday with 0 hours is a day off, and days in days_off are always left out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.7
    • addedInput schema / properties / intervals_days
      Added value: +{
+  "default": [
+    1,
+    3,
+    7,
+    14,
+    30
+  ],
+  "description": "Days after the first study to review.",
+  "items": {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / reviews
      Added value: +{
+  "description": "Topics you are reviewing, with the day you first studied each one.",
+  "items": {
+    "properties": {
+      "exam_date": {
+        "description": "Exam date, if any. Reviews on or after it are skipped. Use 2026-12-12, or plain text like Dec 12, next Friday or in 3 weeks.",
+        "type": "string"
+      },
+      "first_study_date": {
+        "description": "The day you first studied it. Defaults to the plan start date. Use 2026-12-12, or plain text like Dec 12, next Friday or in 3 weeks.",
+        "type": "string"
+      },
+      "topic": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "topic"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  2. First observedv0.1.3

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnlyHint and openWorldHint annotations: it returns the whole file, study sessions become free all-day events, exams become busy all-day events unless include_exams is false, and reviews produce extra events. It also explains topic descriptions and date parsing behavior.

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?

The description is front-loaded with the core purpose and is appropriately sized for a complex export tool. It is somewhat long and includes details that could be tightened, but each part contributes to understanding the output.

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

Completeness5/5

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

Given eight parameters, no output schema, and the need to understand a generated file, the description is complete enough. It explains the return value as a whole .ics file and describes the resulting calendar events, which are the key missing structured information.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still adds useful semantic context for parameters such as include_exams, hours_per_weekday, and reviews by explaining their observable effects on the generated calendar file.

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?

The description gives a specific verb and resource: turning a study plan into an .ics calendar file for import into Google Calendar or Apple Calendar. It also distinguishes itself from build_study_plan by explaining that it builds the same plan but exports it as a calendar file.

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 is clear: use it when you need a calendar-importable file, and the example prompt reinforces the scenario. The relation to build_study_plan is mentioned, but it does not explicitly state when to choose this tool versus build_study_plan or other planning siblings.

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

Deploy Server

Other Tools