# Prior art: calendar surfaces, and the vocabulary they disagree about

**Status:** evidence capture. Not normative, not a discovery-study output.
**Captured:** 2026-08-03 from public documentation and from the frozen discovery snapshot.
**Purpose:** ground the Calendar contract and the open questions recorded in [`profiles/calendar/PROFILE.md`](../../../profiles/calendar/PROFILE.md).

Corpus figures below are mechanical reads of `research/discovery/observations/members.jsonl` and are subject to that cohort's limits ([`FINDINGS.md`](../../discovery/FINDINGS.md)). External surfaces are read from documentation; nothing was invoked.

## Sources

| ID | Surface |
|---|---|
| `C1` | Discovery cohort — 216 calendar-signature tools across 42 of 300 listings |
| `C2` | Google Calendar MCP (`nspady/google-calendar-mcp`) — 12 tools |
| `C3` | Google's official Calendar MCP (`calendarmcp.googleapis.com`) |
| `C4` | Cal.com MCP (`mcp.cal.com`) — 34 booking tools |
| `C5` | The existing Class Profiles Calendar profile — 6 Core verbs, 3 facets |

**Cohort caveat that matters here:** `C1`'s calendar tools are dominated by two gateways wrapping the same Google Calendar API (`GOOGLECALENDAR_*` and `GOOGLESUPER_*` are the same tool set). The cohort alone cannot derive a vocabulary — it would derive Google's. `C2`–`C4` are what make the comparison possible.

---

## The ubiquitous language, and where it fractures

Argument names across `C1`'s 216 calendar tools. Each row is one concept.

| Concept | Spellings observed | Occurrences |
|---|---|---|
| **when it starts / ends** | `timeMin`/`timeMax` 8/8 · `start_date`/`end_date` 9/7 · `startTime` 7 · `start_datetime` 6 · `start`/`end` 5/5 · `date` 12 · `days_ahead` 7 | ~74 |
| **which calendar** | `calendar_id` 28 · `calendarId` 6 | 34 |
| **which event** | `event_id` 21 · `id` 15 · `booking_id` 9 | 45 |
| **which timezone** | `timezone` 15 · `timeZone` 6 | 21 |
| **what it is called** | `summary` 10 · `name` 6 · `subject` 2 | 18 |
| **the longer text** | `notes` 9 · `body` 2 | 11 |
| **who is coming** | `attendees` 8 · `email` 4 · `guests_can_modify` 3 · `maxAttendees` 4 | — |
| **tell people** | `send_updates` 7 · `notification_settings` 2 · `defaultReminders` 2 · `send_notifications` 1 · `alert_level` 1 | — |
| **how many** | `limit` 22 · `max_results` 5 · `pageToken` 6 · `skip` 5 | 38 |

Seven spellings for a time range. Two casings each for calendar, timezone. Three for identity.

### The trap: `summary` means title

Google Calendar names the event's title `summary`, and that spelling leads the cohort at 10 occurrences — ahead of `name` and `subject`.

In almost every other vocabulary, "summary" means an abstract or a condensed description. A model fluent in Google's dialect meeting a differently-named server will put the title where the description belongs, and the failure is silent: the event is created, and it is wrong.

This is the single best argument in the study for a shared vocabulary, because it is not merely fragmentation — it is a **collision**, where the same word means different things in different dialects. Fragmentation costs tokens. Collisions produce wrong results that look like right ones.

## Operation vocabulary

`C1` operation tokens: `get` 60 · `list` 15 · `create` 14 · `search` 13 · `schedule` 6 · `book` 6 · `update` 6 · `delete` 5 · `patch` 4 · `cancel` 4 · `add` 4 · `check` 3 · `find` 3 · `move` 2.

`C2` exposes twelve tools: `list-calendars`, `list-events`, `get-event`, `search-events`, `create-event`, `update-event`, `delete-event`, `respond-to-event`, `get-freebusy`, `get-current-time`, `list-colors`, `manage-accounts`. `C3` is materially the same set.

Three reads — `list-events`, `get-event`, `search-events` — over one target space, distinguished only by how the caller happens to know what it wants.

## Two jobs wearing one noun

`C4` is not a smaller `C2`. It is a different job.

Cal.com's model is **event type → available slots → booking**, with a booking lifecycle (pending, confirmed, rescheduled, cancelled, declined) and availability schedules. Its documentation notes that an availability query needs an `event_type_id` plus an ISO window to return open slots. `C1` corroborates the shape independently: `book` and `schedule` appear as operation tokens 12 times, and `booking_id` appears 9 times as an identity.

The distinction, in the plainest terms:

- `C2`/`C3` — *manage my schedule.* I create, edit, and cancel entries on calendars I control.
- `C4` — *let other people reserve my time.* They pick a slot; a booking is created with a lifecycle I confirm or decline.

They share a target space (time) and almost nothing else. Under the job test ([`decisions/0004`](../../../decisions/0004-capability-is-a-job.md)), these are two classes, and `calendar` is the noun that hides them.

This is direct evidence for the tension `0004` recorded as open: **the flagship class is named after a noun, and the noun covers more than one job.**

## Two findings worth designing against

### The model does not know what time it is

`C2` and `C3` both ship **`get-current-time`** as a tool — *"current date and time in calendar's timezone."*

A calendar tool needs it because every relative expression a user speaks — *"next Thursday", "tomorrow afternoon", "in two weeks"* — requires a now, and a language model has no clock. `C5` currently states that natural-language time is out of scope because *"agents resolve 'next Thursday' while the wire speaks RFC 3339"* ([`spec/05 §10`](../../../spec/05-kernel.md#non-kernel)).

That is only sound if the agent knows the current instant **and the calendar's timezone**. Neither is guaranteed, and getting either wrong produces a confidently-scheduled event on the wrong day. Two independent implementations shipped a tool to close the gap.

### Instance versus series is where implementations diverge

`C2` advertises *"advanced modification capabilities for recurring events,"* including responding to a single occurrence while leaving the rest untouched — *"Accept just this week's standup, but keep future instances as tentative."*

So a recurring event is not one referent. It is a series and its instances, and an edit must say which it means. `C5` has recurrence as a facet but its `event_id` does not distinguish the two, and an earlier review of this proposal flagged that ambiguity as the subtlest line in the profile. `C2` confirms it is real and that implementations invest in it.

## Scope boundaries observed

`C2`'s `manage-accounts` and its rule that *"when no `account` parameter is supplied to a tool, read-only tools merge results from all accounts"* is multi-account routing — which `C5` correctly places in another layer ([`spec/01 §10`](../../../spec/01-concepts.md#non-goals)). Recorded as confirmation that the boundary is drawn where real implementations also draw it.

`C2`'s `list-colors` is a clean vendor member: real, useful, and nothing another calendar need implement.

## Not established here

- No implementation was invoked; all external surfaces are documentation reads.
- `C1`'s calendar subset is Google-dominated and cannot support prevalence claims.
- Nothing here establishes that a shared calendar contract is achievable, only what the vocabulary disagreements are.