Apple Calendar vs Plonk
A side-by-side look at the Apple Calendar and Plonk MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Apple Calendar for os automation work as a local process; choose Plonk for os automation as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Apple Calendar when
- You need dedicated capabilities in the OS Automation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
apple_get_preferences, apple_detect_defaults, apple_update_preferences.
Choose Plonk when
- You need dedicated capabilities in the OS Automation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
get_state, save_workspace, launch_workspace.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | OS Automation | OS Automation |
| Quality signal | 61/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 28 | 17 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 184 | 22 |
| Full listing | View Apple Calendar | View Plonk |
Tools & capabilities
Apple Calendar tools 184
apple_get_preferencesRead the persisted Apple-Tools assistant defaults and routing preferences.apple_detect_defaultsRead saved defaults without probing apps. Set probe_apps=true to discover and persist missing Mail, Calendar, Reminders, and Notes targets; this may open apps and request macOS permissions.apple_update_preferencesPersist assistant defaults such as default lists, folders, calendars, archive mailboxes, and preferred communication routing.apple_detect_digest_folderDetect the preferred Notes folder for daily and weekly digests, and persist it if found.apple_set_digest_folderPersist the dedicated Notes folder that Apple-Tools should use for daily and weekly digests.apple_ensure_digest_folderEnsure a dedicated Notes folder exists for daily and weekly digests, creating it when necessary and persisting the preference.apple_update_contact_preferencesPersist preferred communication routing for a specific contact so Apple-Tools can choose the right channel and target for that person.apple_prepare_communicationResolve a recipient through Contacts, evaluate available channels, and return the recommended mail or messages target before sending.apple_preview_communicationPreview how Apple-Tools will route a communication before sending it through Messages or Mail.apple_preview_archive_messagePreview how Apple-Tools will archive a Mail message before moving it.apple_preview_create_reminder_with_defaultsPreview how Apple-Tools will create a reminder with the configured default reminder list.apple_preview_create_note_with_defaultsPreview how Apple-Tools will create a note with the configured default notes folder.- +172 more on the listing page
Plonk tools 22
get_stateGet the current desktop state: all screens/monitors (index, frame, visible area — coordinates have origin at top-left of the primary screen, y grows down), all open windows (app name, title, which screen it is on, absolute frame, and 'fraction' — its position as fractions 0..1 of that screen's visible area), 'zone_sets' (every set by name, each zone as {x,y,w,h} with a 'name' where the set gives it one), 'screen_zone_sets' (which set each monitor wears), saved layout names, 'app_rules' (where each app's new windows open, see set_app_rule), 'place_new_windows' and 'auto_fill_zones', whether a keep-awake session is holding, and 'disabled_features': the modules the user switched off in Plonk (zones, workspaces, shot, ruler, awake and so on). A tool belonging to one of those fails with an error saying so until the user switches it back on. ALWAYS call this first before applying a layout, to see which apps are running and how many monitors there are.save_workspaceSave a workspace: the apps of a desktop setup, where each window goes, and what each app should open. Pass 'items' to describe the arrangement, or omit them to snapshot the windows exactly as they are on screen right now. Saving over an existing name replaces it. Saved workspaces are listed in get_state, with their full contents.launch_workspaceLaunch a saved workspace: opens every app that is not running, waits for its windows, and moves them into the saved positions. Each window returns to the monitor it was captured on, so a workspace spanning several displays comes back spanning them. macOS cannot open an app straight into a position, so windows appear first and jump into place. Returns per-app success, and reports apps that never opened a window. Takes up to a minute for a large workspace.delete_workspaceDelete a saved workspace by name. Use this to clean up workspaces you created that are no longer wanted.apply_layoutMove and resize windows to build a layout. Each item places one window: 'app' is the app name (fuzzy matched), optional 'title' filters windows of that app by title substring, optional 'screen' is the monitor index from get_state (each monitor can get its own layout — just send items with different 'screen' values; defaults to the screen the window is currently on), 'frame' is {x,y,w,h} as fractions 0..1 of that screen's visible area with origin at TOP-LEFT (left half = {x:0,y:0,w:0.5,h:1}; bottom-right quarter = {x:0.5,y:0.5,w:0.5,h:0.5}; centered 60% = {x:0.2,y:0.15,w:0.6,h:0.7}). Windows are unminimized if needed. Returns per-item success/errors.save_layoutSave the named window arrangement as a workspace. Legacy name kept for older clients — new integrations should call save_workspace, which can also record whether running apps get moved into place. Omit 'items' to snapshot the windows exactly as they are on screen right now; pass 'items' to describe the arrangement explicitly. Saving over an existing name replaces it. Saved workspaces are listed in get_state, with their full contents.apply_saved_layoutLaunch a saved workspace by name. Legacy name kept for older clients — new integrations should call launch_workspace, which adds a 'screen' option to pull the whole workspace onto one monitor. Opens every app that is not running, waits for its windows, and moves them into the saved positions; macOS cannot open an app straight into a position, so windows appear first and jump into place. Returns per-app success and reports apps that never opened a window. Takes up to a minute for a large workspace.snap_windowDrop one window into a zone of the snap-zone set assigned to that monitor, by number or by name. The numbers are the ones Plonk draws on the zones while a window is dragged, so 'the middle zone' of a three-zone set is 2; a name is whatever the set calls a zone ('chat'), listed per zone in get_state.zone_sets, matched ignoring case. Fails with the zones that screen does have, names included, when neither matches. Zone sets and their per-monitor assignment are in get_state; use apply_layout instead when the user describes a size rather than a zone.delete_layoutDelete the saved workspace with that name, whether it was saved with save_layout or save_workspace. Legacy name kept for older clients — new integrations should call delete_workspace, which does the same. Use it to clean up saved workspaces that are no longer wanted; existing names are listed in get_state.save_zone_setCreate or replace a named zone set used for drag snapping. Zones are rectangles {x,y,w,h} as fractions 0..1 of a screen's visible area, origin TOP-LEFT; each zone must stay inside the screen, but zones may overlap each other (the smallest one under the cursor wins). A zone may also carry a 'name' ('chat', 'editor'): it is drawn under the zone's number, the user can say it out loud, and snap_window takes it instead of the number; names must be unique within the set, ignoring case, and cannot be a bare number. Pass 'screen' to also assign the set to that monitor so it becomes active immediately. Pass 'gap' to give this set its own spacing around windows in points, or null to make it follow the default gap again; omitting it keeps whatever the set had. Built-in sets already exist: Halves, Thirds, 60 / 40, Quarters, Priority.assign_zone_setAssign a zone set (built-in or saved) to one monitor, so dragging a window there snaps to that set's zones. Each monitor keeps its own assignment; assigning replaces whatever that monitor used before and takes effect on the next drag. Omit 'name' to restore the default set (Halves); pass 'edge' for plain edge snapping instead of zones. Available set names and current per-monitor assignments are in get_state.delete_zone_setDelete a saved zone set by name. Any monitor currently using it falls back to the default set (Halves), so snapping keeps working. Only sets made with save_zone_set can go: the built-ins (Halves, Thirds, 60 / 40, Quarters, Priority) are refused. Deleting is immediate and cannot be undone — the zones would have to be described again. Saved sets and their per-monitor assignments are listed in get_state; use assign_zone_set instead when a monitor should merely stop using a set that others still need.- +10 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Apple Calendar
{
"mcpServers": {
"apple-calendar": {
"command": "uvx",
"args": [
"apple-tools-mcp"
]
}
}
}
Plonk
{
"mcpServers": {
"plonk": {
"command": "npx",
"args": [
"-y",
"plonk-mcp"
]
}
}
}
Frequently asked questions
Apple Calendar is categorized under OS Automation and uses a local stdio subprocess. Plonk belongs to OS Automation and uses a local stdio subprocess. Pick Apple Calendar for os automation work and Plonk for os automation.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Apple Calendar has no declared pricing — check the project's own site. Plonk has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add apple-calendar and plonk as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Apple Calendar has a quality signal of 61/100 (Good) with 1 views, 0 installs and 28 GitHub stars. Plonk has 64/100 (Good) with 1 views, 0 installs and 17 GitHub stars.