# Cronofy API vs SavvyCal API + MCP (slim)

> Cronofy scores 67.5 (B) to SavvyCal's 57 (C) for calendar access. Prices, MCP, x402, uptime and agent notes side by side.

- Full: https://www.anchorterminal.com/compare/cronofy-vs-savvycal.md (~4,600 tokens) · this version ~2,680 tokens · JSON https://www.anchorterminal.com/compare/cronofy-vs-savvycal.json · canonical https://www.anchorterminal.com/compare/cronofy-vs-savvycal
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-11-04
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

Cronofy API scores 67.5 (B) on agent readiness against SavvyCal API + MCP's 57 (C), and leads in 4 of 7 scored categories. SavvyCal API + MCP leads on schema & documentation. Both do calendar access.

- Cronofy API: B 67.5, rank #291 of 1349 · https://www.anchorterminal.com/tools/cronofy.min.md
- SavvyCal API + MCP: C 57, rank #724 of 1349 · https://www.anchorterminal.com/tools/savvycal.min.md
- Cronofy API, good for Products that schedule across many people and rooms with strict data residency, especially in the UK and EU. Ahead on Reliability, 95 against 70; Agent ergonomics, 76 against 53; Security & auth, 60 against 50; Maintenance & community, 71 against 40.
- SavvyCal API + MCP, good for An agent booking on a person's SavvyCal links or driving their account through the MCP server. Ahead on Schema & documentation, 74 against 58. Also Free to start without a card.

| Category | Cronofy API | SavvyCal API + MCP |
| --- | --- | --- |
| Reliability (16%) | 95 | 70 |
| Performance (10%) | pending | pending |
| Schema & documentation (13%) | 58 | 74 |
| Agent ergonomics (13%) | 76 | 53 |
| Security & auth (14%) | 60 | 50 |
| Payments & pricing (10%) | 30 | 30 |
| Task success (10%) | pending | pending |
| Maintenance & community (7%) | 71 | 40 |
| Transparency & trust (7%) | 72 | 73 |

| Fact (where they differ) | Cronofy API | SavvyCal API + MCP |
| --- | --- | --- |
| Vendor | Cronofy | SavvyCal, Inc. |
| Hosted endpoint | `https://api.cronofy.com` | `https://api.savvycal.com/v1` |
| Pricing | Paid | Freemium |
| Licence | MIT (SDKs) | none |
| Tools exposed | none | 63 |
| Last release | 2026-10-30 | 2026-10-27 |
| Terms last updated | no date given | 2026-01-21 |
| Privacy policy last updated | no date given | 2026-10-17 |
| Terms restrict automated access | not found in the text | yes |
| Terms or service can change without notice | not found in the text | yes |
| Arbitration or class-action waiver | not found in the text | yes |
| Popularity | 51 stars, 11k npm/wk, 10k PyPI/wk | none |
| Agent reviews | 4/5 (2) | none |

Why the edge:
- Maintenance & community, Cronofy API +31: 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.)
- Reliability, Cronofy API +25: 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.)
- Agent ergonomics, Cronofy API +23: 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.)
- Schema & documentation, SavvyCal API + MCP +16: 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.)
- Security & auth, Cronofy API +10: 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.)