Skip to main content
Glama
chrischall

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_create_recurring_chore

Create a recurring chore or routine in Skylight Calendar using an RRULE, start date, and optional time. Assign categories, rewards, or leave unassigned for family members.

Instructions

Create a recurring chore or routine (repeats per an RRULE; verified live).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
startYesYYYY-MM-DD first occurrence date.
frameIdNo
routineNoSet true to create a routine (habit-style recurring task) instead of a chore.
summaryYesChore title.
emoji_iconNo
recurrenceYesiCalendar RRULE without the "RRULE:" prefix, e.g. "FREQ=WEEKLY;INTERVAL=1;BYDAY=MO,WE,FR" (daily: "FREQ=DAILY;INTERVAL=1"). Use BYHOUR for routine time-of-day.
start_timeNoHH:mm time of day (e.g. "17:00").
descriptionNo
category_idsNoFamily-member category ids to assign (omit only with up_for_grabs).
up_for_grabsNoSet true for an unassigned "anyone can do it" chore (requires no category_ids).
reward_pointsNo
recurring_untilNoISO datetime the recurrence ends (e.g. "2026-12-31T23:59:59.999Z").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv0.7.1
    • removedInput schema / properties / category_ids / items / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / category_ids / items / type
      Added value: +[
+  "string",
+  "number"
+]
  3. First observedv0.4.6

TDQS

B3.4/5.0
Behavior3/5

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

Annotations only say the tool is non-read-only and non-destructive; the description adds that recurrence uses an RRULE and is 'verified live,' which hints at validation behavior. It does not disclose side effects, permission requirements, or what happens on invalid recurrence, but given annotations cover the basic safety profile, the extra recurrence detail earns a mid score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It states the action, the resource, and a key behavioral property in one line, which is appropriately concise for a description.

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

Completeness2/5

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

Despite 12 parameters, no output schema, and nuanced sibling tools (create_chore, create_task, update_chore), the description is only one sentence. It leaves the chore/routine distinction, return value, required-parameter relationships (e.g., category_ids vs up_for_grabs), and frame association unexplained. The schema carries most of the load, and the description is not complete enough for an agent to confidently invoke the 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 already documents most parameters (67% coverage), including the recurrence format and routine flag. The description's mention of RRULE and routine adds little beyond the schema and does not clarify undocumented parameters like frameId, emoji_icon, description, or reward_points. The description is adequate but does not compensate for the schema gaps.

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?

States a specific verb and resource ('Create a recurring chore or routine') and adds a distinguishing technical detail (RRULE-based recurrence). The description clarifies that the tool also creates routines, which helps differentiate it from skylight_create_chore, but it does not fully articulate the chore-vs-routine distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'recurring chore or routine' implies the tool is for repetitive tasks, but there is no explicit guidance about when to choose this over skylight_create_chore or skylight_create_task, nor any exclusions for non-recurring chores. Usage must be inferred from the name and the word 'recurring.'

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