Calendar MCP vs Dreamwork
A side-by-side look at the Calendar MCP and Dreamwork MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Calendar MCP for workplace & productivity work as a local process; choose Dreamwork for workplace & productivity over a hosted endpoint. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Calendar MCP when
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET. - You want tools like
list_accounts, get_preferences, set_preferences.
Choose Dreamwork when
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: API key required.
- You want tools like
list_matches, get_job, save_job.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Workplace & Productivity | Workplace & Productivity |
| Quality signal | 61/100 · Good | 71/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Remote HTTP/SSE |
| Auth | Not declared | API key required |
| Pricing | Not declared | Not declared |
| Required env vars | GOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRET | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 26 | 11 |
| Directory activity | 2 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 23 | 69 |
| Full listing | View Calendar MCP | View Dreamwork |
Tools & capabilities
Calendar MCP tools 23
list_accountsList the Google accounts calendar-mcp can use, and which is the default. Every other tool takes an optional `account` argument naming one of these. An account whose `valid` is false needs `calendar-mcp auth --account <name>` run once in a terminal before its calendars can be read.get_preferencesRead the user's scheduling preferences: working hours, lunch, buffers, focus. Consult this before proposing meeting times or hunting for focus blocks, rather than assuming a nine-to-five. Never configured returns the defaults (Mon-Fri 09:00-17:00, no lunch break, no buffer), which is a reasonable guess but worth confirming with the user before you rely on it.set_preferencesUpdate the user's scheduling preferences and save them. Returns the merged result. Only the arguments you pass change; everything else keeps its current value, so a single correction ("I actually start at 8") does not have to restate the whole schedule. The merged result is validated before it is written, so a rejected change leaves the saved preferences untouched. Args: timezone: IANA timezone the working hours are expressed in, e.g. 'Europe/Berlin'. Must be a real zone name. working_hours: Whole-schedule replacement, keyed by weekday ('mon'..'sun'), each value a list of ['HH:MM', 'HH:MM'] pairs. Days you omit become non-working, so pass every working day at once, e.g. {"mon": [["09:00", "12:00"], ["13:00", "18:00"]], "fri": [["09:00", "15:00"]]}. buffer_minutes: Minimum gap to leave before and after each meeting when proposing times. 0 disables it. min_focus_block_minutes: Shortest free stretch that still counts as usable focus time. lunch: Daily lunch break as ['HH:MM', 'HH:MM'], carved out of the working hours. focus_calendar_id: Calendar that focus blocks are booked on; 'primary' for the user's own. clear_lunch: Set true to remove an existing lunch break (pass this instead of `lunch` when the user says they no longer want one).analyze_busynessSummarise how loaded each day is: event count and total scheduled minutes. Use this to answer "how busy is my week" without listing every event. Args: time_min: Start of the window, ISO 8601. time_max: End of the window, ISO 8601. calendar_id: Calendar to analyse. account: Account name from 'calendar-mcp accounts'; omit for the default.project_recurring_eventsCompute future occurrences of recurring events from their recurrence rules. Unlike `find_events`, this expands the RRULEs locally, so it reaches past the horizon Google materialises instances for -- useful for "when do my birthdays / standups land next year". Args: time_min: Start of the projection window, ISO 8601. time_max: End of the projection window, ISO 8601. calendar_id: Calendar whose recurring events should be projected. event_query: Only project recurring events matching this text, e.g. 'Birthday'. account: Account name from 'calendar-mcp accounts'; omit for the default.time_auditReport where the user's time went: meeting hours, who with, and what focus time is left. Answers "how much of my week is meetings?", "who am I spending my time with?" and "where did my focus time go?" in one pass. Working hours, lunch, buffer and the minimum focus block come from the saved preferences (see get_preferences), so the percentages reflect this user's actual day. Declined meetings, events marked 'free', and all-day entries are excluded by default; the 'excluded' field says how many were skipped. Args: time_min: Start of the window to audit, ISO 8601. time_max: End of the window to audit, ISO 8601. calendar_ids: Calendars to include. Defaults to ['primary']. group_by: Break the window down by 'day' or by ISO 'week'. include_all_day: Count all-day events as meeting time. include_declined: Count meetings the user declined. account: Account name from 'calendar-mcp accounts'; omit for the default.list_calendarsList the calendars the signed-in user can see, with their IDs and timezones. Start here whenever the user mentions a calendar other than their own: the `id` values returned are what every other tool's `calendar_id` expects. Args: min_access_role: Only return calendars where the user has at least this role: 'freeBusyReader', 'reader', 'writer' or 'owner'. Omit for all. account: Account name from 'calendar-mcp accounts'; omit for the default.create_calendarCreate a new secondary calendar owned by the user. Args: summary: Name for the new calendar, e.g. 'Client work'. account: Account name from 'calendar-mcp accounts'; omit for the default.find_focus_timeFind the uninterrupted blocks in a window that could be used for deep work. Searches inside the user's working hours (`get_preferences`), removes lunch, everything already booked on their calendars, and the buffer they like around meetings, then reports what is left -- longest block first, because that is the one worth protecting. Blocks shorter than `min_focus_block_minutes` are not reported at all. Availability must be readable for every requested calendar; otherwise this returns an error rather than unverified free time. Read-only: use `block_focus_time` to actually defend the time. Args: time_min: Start of the window to search, ISO 8601. Without a UTC offset it is read in the calendar's own timezone. time_max: End of the window to search, ISO 8601. hours_needed: How many focus hours the user is trying to find. Used to report whether the window can supply them; pass 0 to just look. calendar_ids: Calendars whose events count as busy. Omit for every calendar the account has selected. account: Account name from 'calendar-mcp accounts'; omit for the default.block_focus_timeBook the best free blocks in a window as focus time, until the hours add up. Takes the blocks `find_focus_time` would report, longest first, and creates an event on each until `hours_needed` is covered. The last block is trimmed to what is still needed rather than swallowing a whole afternoon. Events are created busy, with reminders off and without notifying anyone. Run it with `dry_run` first when the user has not yet agreed to the times. Both preview and booking fail before writing if any checked calendar has unknown availability. The destination calendar is always checked too. Args: time_min: Start of the window to book inside, ISO 8601. time_max: End of the window, ISO 8601. hours_needed: How many focus hours to book. title: Title for the blocks. Default 'Focus time'. calendar_id: Calendar to book on. Omit for the user's configured focus_calendar_id (see `get_preferences`). check_calendar_ids: Calendars whose events count as busy. Omit for every calendar the account has selected. description: Optional note to put in each block. dry_run: True to report the blocks that would be booked without writing anything to the calendar. account: Account name from 'calendar-mcp accounts'; omit for the default.detect_conflictsFind double-booked events in a window, across every signed-in account. Reports two things. `conflicts` are genuine overlaps -- the user cannot be in both places. `tight` transitions do not overlap but leave less than the buffer from `get_preferences`, which is what makes a day feel impossible. Events the user declined, events marked free, cancelled events and (unless `include_all_day` is set) all-day events are ignored, because none of them actually occupy the user. Args: time_min: Start of the window to check, ISO 8601. time_max: End of the window to check, ISO 8601. accounts: Account names to check. Omit for every signed-in account, which is the point of the tool -- a work meeting clashing with a personal one is invisible from either calendar alone. calendar_ids: Restrict to these calendars (in every account checked). Omit for each account's selected calendars. include_all_day: True to let all-day events clash with timed ones. max_events_per_calendar: Safety limit per calendar. Default 250.suggest_reschedulePropose better times for an existing meeting, ranked, keeping its length. Reads the event, then looks for slots of the same duration inside the user's working hours where the organiser is free, and ranks them: fewest attendee conflicts first, the event's current day next, then earliest. Slots that sit closer to another meeting than the user's buffer allows are penalised, not hidden. Read-only by default -- it suggests, the user decides. Set `apply` to move the event to the top suggestion once they have agreed to it. Args: event_id: The event to reschedule (from `find_events`). calendar_id: Calendar the event lives on. search_days: How many days ahead to search. Default 7, maximum 60. max_suggestions: How many times to propose. Default 5, maximum 20. search_from: Start searching from this time, ISO 8601. Defaults to now. apply: True to actually move the event to the best suggestion. Only set this when the user has agreed to the time. account: Account name from 'calendar-mcp accounts'; omit for the default.- +11 more on the listing page
Dreamwork tools 69
list_matchesReturns the account's ranked live match pool with job id, its Dreamwork page url, title, company, location, remote terms, salary, dates, match percent and saved/applied state. Filters narrow that pool; nextCursor continues a page with identical filters, and null ends the walk. A page holds 10 jobs by default and limit accepts up to 50; the next page is the previous nextCursor, which keeps the page size it was issued with. addedAfter supports overlapping discovery windows because listings can become servable after first discovery. notes describe applied filters and coverage.get_jobReturns one saved or corpus role by id with full description, company, location and remote terms, salary, posted date, match score, saved state, board column, application id, material readiness and work-eligibility verdict. url is the Dreamwork listing page; sourceUrl is the employer's direct posting. eligible is true for an unrestricted role or a confirmed allowed country, false for a high-confidence restriction excluding confirmed countries, and null when eligibility is unknown. Only false blocks applying or Autopilot: null means eligibility is not yet known, so proceed with applying — the application itself surfaces any real restriction. whyItMatches may be empty when no matcher explanation is stored.save_jobSaves one role to the account's pipeline at SAVED as a bookmark. No application is submitted or queued until apply is called. Application materials may start preparing in the background. An already saved role returns a no-op receipt.dismiss_matchHides one listing from the account's match feed, job alerts and Autopilot until the account restores or saves it. The receipt offers undo for one minute; restore_match reverses it at any time and list_dismissed_matches lists dismissed listings. The supplied reason is not stored. It does not hide other listings from the same company and does not move or remove an existing pipeline card.restore_matchReverses a dismissal of one listing so it can return to the account's match feed, job alerts and Autopilot. Restoring a listing that is not dismissed returns a no-op receipt. Restoring does not save the listing. A closed listing stays out of the feed.list_dismissed_matchesReturns the account's dismissed listings, newest first, with listing id, title, company, Dreamwork page url, dismissal time and whether the listing is still active. total counts all dismissed listings. limit defaults to 20 and accepts up to 50; nextOffset continues the list and null ends it.get_pipelineReturns saved and applied roles as board cards with column, application id and last-updated time. total and counts cover all matching records; complete identifies whether cards are truncated by limit. limit defaults to 50 cards and accepts up to 100; there is no next page, so when complete is false narrow the read with status. Column values describe board state and do not establish employer receipt or response.move_pipelineMoves one role's board card to the requested column using the account holder's reported state. No employer is contacted. APPLIED records an application rather than submitting one; INTERVIEWING creates a durable interview record. WITHDRAWN removes the card from the active board. Closing a role can remove its listing from the feed. A receipt offers undo only when reversible.mark_applied_offsiteRecords an application the account holder submitted outside Dreamwork. Exactly one of matchId, listingId or url names the role; a role not yet in the pipeline is added in Applied without generating materials, and an unlisted URL is imported in the background. appliedAt (YYYY-MM-DD or ISO 8601, not in the future) is the reported application date and defaults to now; repeating the call with a new appliedAt corrects it. attestation:true is required and represents the person's confirmation that submission occurred. Recorded roles are excluded from matches and Autopilot. Applications Dreamwork is still sending are refused. There is no undo. This call does not send an application.import_jobFetches a public job-posting URL and imports it as a private role in the account's pipeline. Extraction runs asynchronously and the card appears when it finishes. A posting already held by Dreamwork returns completed without another fetch.cancel_applyStops a queued or in-progress application when submission can still be prevented. Already submitted applications cannot be recalled; the receipt reports that boundary.generate_packQueues a tailored resume, cover letter and employer-question answers for one saved role. assets optionally selects a subset; omission requests all three. Each request spends one pack allowance, regardless of subset, and generation settles asynchronously. Existing materials can be overwritten by generation.- +57 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.
Calendar MCP
{
"mcpServers": {
"calendar-mcp-2": {
"command": "uvx",
"args": [
"calendar-mcp-server"
],
"env": {
"GOOGLE_CLIENT_ID": "YOUR_GOOGLE_CLIENT_ID_HERE",
"GOOGLE_CLIENT_SECRET": "YOUR_GOOGLE_CLIENT_SECRET_HERE"
}
}
}
}
Dreamwork
{
"mcpServers": {
"dreamwork-2": {
"command": "npx",
"args": [
"-y",
"@dreamworkhq/mcp"
]
}
}
}
Frequently asked questions
Calendar MCP is categorized under Workplace & Productivity and uses a local stdio subprocess. Dreamwork belongs to Workplace & Productivity and uses a remote HTTP/SSE transport. Pick Calendar MCP for workplace & productivity work and Dreamwork for workplace & productivity.
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.
Calendar MCP has no declared pricing — check the project's own site. Dreamwork has no declared pricing — check the project's own site. Auth: api key required. 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 calendar-mcp-2 and dreamwork-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Calendar MCP has a quality signal of 61/100 (Good) with 2 views, 0 installs and 26 GitHub stars. Dreamwork has 71/100 (Great) with 2 views, 0 installs and 11 GitHub stars.