MCP server for Motion calendar — full calendar event access, availability checking, and task management. Uses Motion's internal API for calendar features the public API doesn't support.
Motion MCP has well-structured tool definitions with consistent naming (verb_noun pattern), complete input schemas with types and descriptions, and clear parameter documentation. All 13 tools follow the verb_noun convention (list_, create_, update_, delete_, search_, check_, find_, get_). Descriptions are present and actionable (avg ~120 chars). However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling is minimal; no recovery guidance or actionable error messages visible in code. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Missing idempotency guarantees for write operations. Composition is sound, tools are single-responsibility and chainable (e.g., list_calendars → create_event). Security: credentials injected via env vars (correct pattern). Rate limiting implemented. No validation of enum constraints or date formats visible in tool handlers.
Check your availability for a given date range and duration. Returns free time slots within working hours.
Create a new calendar event. Defaults to your primary calendar if no calendar_id is specified.
Create a new task in Motion.
Delete a calendar event by ID.
Delete a task from Motion.
Find available meeting slots for multiple attendees. Returns times when all participants are free.
Get all-day events for a date range. Useful for identifying PTO, conferences, or other day-blocking events.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., list_events returns event objects but structure is not declared.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are risk-stratified (READ_ONLY, WRITE, DESTRUCTIVE) but this is not exposed to the MCP client. Agents cannot distinguish safe from dangerous operations.
Error handling lacks recovery guidance. No visible error messages that tell LLMs what to do next (retry, ask user, lookup alternative). Errors are generic HTTP status codes without actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List all calendars connected to your Motion account. Returns calendar names, IDs, email accounts, and whether they are enabled.
List calendar events within a date range. Returns event titles, times, attendees, locations, and conference links.
List tasks from Motion. Can filter by status, project, or assignee.
Search calendar events by text query. Searches event titles and descriptions.
Update an existing calendar event by ID.
Update an existing task in Motion.
No idempotency guarantees for write operations (create_event, create_task, update_event, update_task). Agents retry on ambiguous failures, without idempotency keys or deduplication, duplicate side effects are possible.
Input validation not visible in tool handlers. Enum constraints (status, visibility, conference_type, priority) are declared in schema but no validation logic shown. Invalid inputs may reach the API.