Skip to main content
Glama
Sign In
mjucius

Cozi MCP Server

by mjucius
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create a calendar appointment

create_appointment

Create a calendar appointment. start and end are ISO datetimes (e.g. '2026-06-15T10:00:00'). For all-day events (all_day=true) a bare date (e.g.

Instructions

Create a calendar appointment. start and end are ISO datetimes (e.g. '2026-06-15T10:00:00'). For all-day events (all_day=true) a bare date (e.g. '2026-06-15') is also accepted and end may equal start; a bare date on a timed event is an error. For a multi-day event put end on a later date — the span is preserved, and the result reports it as end_day. end before start is an error. For attendees, call family_members() first and pass those id values. For a repeating event pass repeat; start/end are then its first occurrence.

Input Schema

NameRequiredDescriptionDefault
endYes
notesNo
startYes
notifyNoSend Cozi's change notification to the attendees who have notifications on, like the Cozi app's 'notify' option. Off by default; only when the user asks for it.
repeatNoMake it repeat. `interval` 2 = every other day/week/month/year. Weekly: `weekdays` (e.g. ['MO','WE']; default the start's weekday, which must be included). Monthly/yearly: `monthly_by` 'day_of_month' (default, e.g. the 15th) or 'weekday' (e.g. the 2nd Tuesday; a 5th weekday means the last). `until` is the last possible day (YYYY-MM-DD); omit it to repeat forever.
all_dayNo
subjectYes
locationNo
attendeesNo
remindersNoReminder lead times in minutes before the start, e.g. [30, 1440]. [] clears them on an update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.5.0
    • addedInput schema / properties / notify
      Added value: +{
+  "description": "Send Cozi's change notification to the attendees who have notifications on, like the Cozi app's 'notify' option. Off by default; only when the user asks for it.",
+  "type": "boolean"
+}
    • addedInput schema / properties / reminders
      Added value: +{
+  "description": "Reminder lead times in minutes before the start, e.g. [30, 1440]. [] clears them on an update.",
+  "items": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / repeat
      Added value: +{
+  "additionalProperties": false,
+  "description": "Make it repeat. `interval` 2 = every other day/week/month/year. Weekly: `weekdays` (e.g. ['MO','WE']; default the start's weekday, which must be included). Monthly/yearly: `monthly_by` 'day_of_month' (default, e.g. the 15th) or 'weekday' (e.g. the 2nd Tuesday; a 5th weekday means the last). `until` is the last possible day (YYYY-MM-DD); omit it to repeat forever.",
+  "properties": {
+    "frequency": {
+      "enum": [
+        "daily",
+        "weekly",
+        "monthly",
+        "yearly"
+      ],
+      "type": "string"
+    },
+    "interval": {
+      "minimum": 1,
+      "type": "integer"
+    },
+    "monthly_by": {
+      "enum": [
+        "day_of_month",
+        "weekday"
+      ],
+      "type": "string"
+    },
+    "until": {
+      "type": "string"
+    },
+    "weekdays": {
+      "items": {
+        "enum": [
+          "SU",
+          "MO",
+          "TU",
+          "WE",
+          "TH",
+          "FR",
+          "SA"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "frequency"
+  ],
+  "type": "object"
+}
  2. First observedv2.0.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavior: which inputs are errors (bare date on timed event, end before start), that multi-day spans are preserved and reported as `end_day`, and that repeat changes the meaning of start/end. It omits permissions/auth and whether adding attendees produces side effects beyond the schema-documented `notify` flag.

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?

Front-loads the core action, then spends each sentence on a distinct rule (formats, all-day, multi-day, errors, attendees, repeat). Some of the repeat prose overlaps the schema's own `repeat` description, but there is little outright waste.

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?

For a 10-param mutation tool with no annotations and no output schema, the definition covers the temporal and validation semantics an agent most needs to call it correctly. Gaps remain around non-temporal fields and the broader return shape beyond `end_day`, but nothing critical to a successful call is missing.

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 only 30% across 10 params, so the description must compensate, and it does for the most error-prone fields: ISO formats for `start`/`end`, all_day date semantics, multi-day span rules, attendee id sourcing, and repeat start/end semantics. It leaves subject, location, notes, and reminders to the schema (which documents notify and reminders), so it is strong but not exhaustive.

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?

Opens with a specific verb+resource ('Create a calendar appointment') that clearly separates it from update_appointment/delete_appointment, and the rest of the text is unambiguous about scope. An agent knows immediately this is the creation path for calendar entries.

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?

Explicitly routes the agent: 'For attendees, call family_members() first and pass those id values,' and explains when repeat applies (start/end become the first occurrence). It does not state when to prefer update_appointment over re-creating, so it stops short of full alternative coverage.

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