Server has 13 well-named tools with consistent verb_noun patterns (list_, get_, create_, update_, delete_, find_, check_, analyze_, summarize_). All tools have descriptions (10-200 chars, within baseline 34-392 range). Input schemas are present and mostly complete with type definitions and parameter descriptions. However, output schemas are entirely undocumented, LLMs cannot predict response structure for chaining. Error handling is minimal; no recovery guidance or actionable error messages visible. Security: no tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Missing: per-parameter validation rules, enum constraints for ambiguous fields, and confirmation patterns for destructive ops.
Analyze calendar blocks
Check availability at time
Create a new calendar event with optional attendees/invitations and optional recurrence. Account is auto-selected from calendarId.
Delete a calendar event
Find best meeting times using user preferences from config (day-of-week ranking, adjacent to meetings, avoid deep work, never-available patterns)
Find meetings with someone
No output schemas documented. LLMs cannot predict response structure, breaking tool chaining. E.g., list_calendar_events returns what fields? Does it include event_id for get_meeting_by_id? Does it include attendee emails for find_meetings_with_person?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY, WRITE, DESTRUCTIVE in metadata but not exposed to LLM via schema. LLM cannot reason about safety or retry semantics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Get meeting details by ID
Get upcoming meetings
List configured Google accounts for multi-account calendar access
List all calendars
List calendar events from all calendars with flexible date filtering
Summarize meetings for period
Modify the recurrence rule of an existing event. scope='series' replaces RRULE on the master; scope='this_and_following' splits the series at splitAt; scope='single' overrides one instance.
Destructive operations (delete_event) lack confirmation pattern. No dry-run, no explicit confirmation step. Agent could delete events without user approval.
Parameter descriptions lack validation rules. E.g., startDate/endDate accept 'YYYY-MM-DD or ISO format' but no regex pattern or format constraint. LLM may pass invalid dates. daysBack defaults to 90 but no min/max bounds stated.
No error handling guidance visible. If create_event fails (e.g., attendee not found, time conflict), what should LLM do? Retry? Ask user? No recovery hints provided.