Cronofy API vs SavvyCal API + MCP

Cronofy API 71

Cronofy's UI Elements, the JavaScript components it publishes for its API, carry a dated changelog in the docs with three code releases in October 2026, 1.68.0 (15 October, Romanian language support), 1.68.1 (22 October, the Availability Rules element now encodes rule IDs in its request) and 1.68.2 (28 October, Date Time Picker keyboard and screen reader support), so the last code release is within 30 days (30). pycronofy 2.1.2 (30 October) and 2.1.1 (25 September) change only packaging, 2.1.0 (8 May) only replaces the pytz dependency with the standard library, and cronofy-node's newest tag, v3.8.4 (15 September 2025), bumps axios. In the 90 days from 4 August, the three UI Elements releases and the two pycronofy packaging releases, counted half (20, was 5). Support through the docs, support pages and support@cronofy.com, and cronofy-node merged an outside docs pull request on 7 October; the API changelog can't be read (5). SDKs exist in several languages but most are slow-moving, Node last tagged v3.8.4 on 15 September 2025 and Ruby last tagged in 2023 (8). CI on the Node and Python SDKs, with Python 3.15 added on 30 October 2026 (8). 30+20+5+8+8 = 71.

SavvyCal API + MCP 40

Read as a closed service. The newest dated change is the MCP integration of 27 October 2026 on the updates board (30). It is the only dated entry since 7 July, so fewer than three in 90 days (0 of 20). A public updates board, a feature request board and a support address with a stated 24-hour reply within US Central business hours (10 of 15). No official SDKs (0). No package to assess (0). 30 + 0 + 10 + 0 + 0 = 40.

Cronofy API 95

Atlassian Statuspage at status.cronofy.com with the API, Scheduler, Meeting Agents and each calendar provider as components (20). history.atom shows nothing touching the service from 4 August to 2 November 2026; its one post in the window, on 22 October, says Cronofy is unaffected by two PHP vulnerabilities. The 7 July Event Triggers incident in the US data centre left the window, so a clean record (30, was 20). 50 requests a second and 500 in any 60 seconds by default (15). 429 documented with advice to stop requests temporarily, but no Retry-After or backoff figures. Event writes are upserts keyed on your event_id, so a repeat updates rather than duplicates (10). 99.99% uptime guarantee on Emerging and Growth, and an API SLA policy page (10). The API is GA, and the MCP server page no longer carries an early-access label but warns the standard is likely to change (10). 20+30+15+10+10+10 = 95.

SavvyCal API + MCP 70

Read with the hosted lines. Instatus page at savvycal.instatus.com with App, Microsoft 365, Google Calendar and Integrations components and a month-by-month history (20). No notices from June to November 2026 and 100 per cent App uptime each month, a clean record (30). The only limit with a number is in the OpenAPI spec, 10 event creations a minute per link, failed ones included; nothing covers the rest of the API (7 of 15). That 429 is declared with no Retry-After, backoff guidance or idempotency key, and webhooks are the only place retries are described (3 of 15). No SLA; the terms give the service as is (0). The v1 API is generally available and the MCP server, announced 27 October 2026, is not marked beta (10). 20 + 30 + 7 + 3 + 0 + 10 = 70.

Cronofy API 76

API responses can be narrowed, for example Availability's response_format of slots and the only_managed flag on events (15). Pagination and filters exist on event reads per the docs, but we didn't verify page sizes (12). Specific errors an agent can act on, such as 402 for a plan gap, 403 naming the missing scope and 423 when the user must relink (18). Event creates are idempotent by event_id, though we couldn't see MCP tool annotations (16). Official SDKs in Node, Python, Ruby, C# and more (15).

SavvyCal API + MCP 53

List responses are sized by limit (default 20, at most 100) with no field selection. The MCP server lists 63 tools with no documented toolset or read-only list, though a client can ask for the mcp:read scope alone (10 of 25). Cursor pagination with after, before and limit, and date and status filters on events (17 of 20). Errors name the field, the failed validation and a limit count, which an agent can act on, but a 429 carries no wait time (14 of 20). No idempotency key on booking or link creation, and the MCP annotations could not be read; the docs say the assistant confirms before cancelling, deleting or inviting (6 of 20). Creating an event needs five fields, and there is no official SDK in any language (6 of 15). 10 + 17 + 14 + 6 + 6 = 53.

Cronofy API 58

No OpenAPI or other machine-readable contract found (0). llms.txt with about 35 to 40 links and Markdown copies of pages (10). Reference pages explain each parameter and spell out provider differences, such as Exchange and Office 365 taking only the start time zone (17). Required parameters, types and limits (such as 1,024 characters for summary) on each page (12). Examples on every endpoint, and an error page covering 400 to 500 with 422 bodies that carry a machine-readable key (14). /v1 in the path. The changelog at changelog.cronofy.com is on a host whose robots.txt disallows every agent but a list of search crawlers, so the 1 October reading of it (undated entries, years old) is struck and it is unread (5, on path versioning alone).

SavvyCal API + MCP 74

OpenAPI 3.0.0 at api.savvycal.com/v1/spec covers all 22 operations with 56 schemas; the MCP tools' schemas could not be read without signing in (23 of 25). llms.txt and a Markdown twin of every docs page (10). Only 8 of the 22 operations carry a description, and those state constraints (events must match an open slot, an invalid filter resets every filter) rather than when to choose another endpoint (10 of 20). Required flags on 14 of 43 parameters, 34 enum properties across the schemas, limit bounded 1 to 100, until at most 31 days after from (12 of 15). Example values on parameters and a documented error shape keyed by field, with 400, 401, 404, 422 and 429 declared per operation, but no full response examples (10 of 15). A /v1 path and a promise that changes are additive, with dated product updates on the feedback board but no API changelog (9 of 15). 23 + 10 + 10 + 12 + 10 + 9 = 74.

Cronofy API 60

Per-user OAuth with fine scopes, including free_busy alone, read_only, and delete_event separate from create_event. Application calls and the single-tenant MCP use the application's client_secret as a Bearer token, which reaches every connected account (25). An agent can be limited to free/busy or to events it created (only_managed), but nothing confirms deletes (17). Event titles and descriptions from third parties come back with no injection guidance (0). No operator audit log found (0). ISO 27001, 27018 and 27701, SOC 2 Type 2 and a public bug bounty policy. No security.txt, per the 30 September check (18).

SavvyCal API + MCP 50

OAuth 2 authorisation code apps with 2-hour access tokens and refresh tokens, and personal access tokens, both in the Authorization header only. The spec declares no scopes for either, and PAT expiry and revocation are not described. The MCP server uses OAuth 2.1 with PKCE S256, dynamic client registration, mcp:read and mcp:write scopes and a revocation endpoint (22 of 30). mcp:read gives a read-only MCP grant, and the vendor says the assistant asks before booking, cancelling, deleting or inviting. REST tokens have no read-only form (14 of 20). Invitee names, answers and metadata written by outsiders come back through events and webhooks with no injection guidance; the AI page says the assistant sees calendar conflicts but not event names (2 of 15). Webhook request logs and a Connected Apps list with revoke, but no per-call audit log for the operator (4 of 15). Valid security.txt to 2 May 2027, a security page and an SSDLC page, but no SOC 2 or ISO 27001 (the page says not yet) and no bug bounty (8 of 20). 22 + 14 + 2 + 4 + 8 = 50.