Skip to main content
Glama
chrischall

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_create_recurring_chore

Create recurring chores or routines for Skylight Calendar with RRULE scheduling, start dates, and optional assignments. Automate household tasks and set rewards.

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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/safety profile is covered structurally. The description adds the RRULE basis for recurrence and a vague 'verified live' claim, but nothing about permissions, assignee requirements, or what happens to conflicting existing chores.

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?

A single front-loaded sentence with no waste; the parenthetical 'verified live' is the only slightly opaque addition, but overall it is tight and well-structured.

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

Completeness3/5

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

For a 12-parameter mutation tool with no output schema, the description is thin: it omits the chore-vs-routine relationship to sibling tools and provides no return or failure context. The schema carries most of the load, leaving the description only minimally complete.

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 67% and the schema itself documents the critical params (recurrence format, routine toggle, category_ids/up_for_grabs rule). The description adds little beyond restating the recurring/routine distinction, so the mid-range baseline of 3 is appropriate.

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 the 'recurring' qualifier implicitly separates it from the sibling skylight_create_chore. It stops short of naming that sibling explicitly, so an agent must infer the non-recurring counterpart.

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 word 'recurring' implies when this tool applies, but there is no explicit when-to-use guidance, no exclusions, and no reference to skylight_create_chore as the non-recurring alternative, nor to skylight_update_chore for edits.

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