Calendar MCP vs Human Survey
A side-by-side look at the Calendar MCP and Human Survey 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 Human Survey for workplace & productivity as a local process. 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 Human Survey when
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
HUMANSURVEY_API_KEY. - You want tools like
login, get_catalog, list_forms.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Workplace & Productivity | Workplace & Productivity |
| Quality signal | 61/100 · Good | 60/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 | GOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRET | HUMANSURVEY_API_KEY |
| Verified owner | Community listing | Community listing |
| GitHub stars | 26 | 1 |
| Directory activity | 2 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 23 | 10 |
| Full listing | View Calendar MCP | View Human Survey |
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
Human Survey tools 10
loginSign in with an email address and store an API key on this machine. Called with only an email, it mails a six-digit code and returns nothing usable — the code has to come from the person, out of their inbox. Called with the email and that code, it stores a key at ~/.humansurvey/credentials and reports where it was written. The key itself is never printed. Signing in and signing up are the same act: an address that has never been used gets an account.get_catalogList the platforms HumanSurvey knows: the slug to use as catalog_slug, the display label, and which class of channel it is. These are the named channels a respondent can be shown — TikTok, ChatGPT, LinkedIn, Reddit and so on — plus the descriptive options that have no brand behind them, like "a friend or colleague told me". No API key needed.list_formsList the forms on this account: id, name, respondent URL, whether it is active or paused, whether it has been configured with questions yet, and how many responses it has collected.get_formRead one form: its settings, and the question configuration currently shown to respondents — every question, every candidate, and the order mode. Returns the configuration as JSON, because that is the exact shape a configuration write takes.create_formCreate a form and return its id, its respondent URL, and the iframe and postMessage listener to embed that URL in a host page. The form has no questions yet and shows nothing to respondents until it is configured. allowed_origins restricts which sites may embed it; leaving it empty allows any site, which means any site can spend this account’s response quota.configure_formSet the questions and candidates a form shows. Replaces the whole configuration and stores it as a new immutable version, so responses already collected keep describing the list they were actually shown. Re-sending an identical configuration reuses the existing version rather than making another. A form is one single-select question, optionally expanding into a second. Give a candidate an `expands` naming another question to reveal it when that candidate is picked — that is how "TikTok" becomes "which account". Candidate ids must be stable keys that survive a rename. Using a handle as an id splits that creator’s history in two the day they change it. Set catalog_slug to take a candidate’s label and logo from the platform catalog. Order defaults to "rotate", which randomizes per respondent and is what makes the reported shares unbiased; "fixed" keeps your order and accepts that earlier options get picked more often for being earlier.get_attributionWhat respondents said, aggregated. Reports, per question, how many completed responses named each candidate out of how many answered that question, the unresolved answers in the same list, how often a follow-up question failed to find an answer, and revenue where conversion events have been recorded. Computed fresh on every call, including any mappings made since — so a rollup of a past window can legitimately change between two reads.list_unresolvedThe answers respondents typed instead of picking from the list, grouped by the exact text and ordered by how often it was typed. Reports the spelling variants seen, when each was first and last typed, and whether a mapping already covers it. These are verbatim words. Two texts that read alike may be different people, and a text may name somebody who is not on the candidate list at all.remapRecord that a specific typed answer means a specific candidate. It applies to every response already carrying that text as well as every future one, so numbers reported for past windows change. The original text is never altered and a mapping can be revoked, but a report may already have been read. Only map a text whose meaning is established — a text that merely resembles a candidate’s name is not evidence that it is that candidate. One live mapping per text per question.revoke_remapStop a mapping from applying. The typed answers it covered return to the unresolved list — in past windows as well as future ones, because rollups join mappings when they are read rather than when they are made. Numbers already reported for those windows will therefore change. Nothing is deleted: the mapping is marked revoked and kept, so a report produced while it was live can still be explained. Revoking an already-revoked mapping is not an error and does not move the time it stopped applying. Mapping ids appear beside any text that is already mapped in the free-text listing, and in the confirmation given when a mapping is created.
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"
}
}
}
}
Human Survey
{
"mcpServers": {
"sunsiyuan-human-survey": {
"command": "npx",
"args": [
"-y",
"humansurvey-mcp"
],
"env": {
"HUMANSURVEY_API_KEY": "YOUR_HUMANSURVEY_API_KEY_HERE"
}
}
}
}
Frequently asked questions
Calendar MCP is categorized under Workplace & Productivity and uses a local stdio subprocess. Human Survey belongs to Workplace & Productivity and uses a local stdio subprocess. Pick Calendar MCP for workplace & productivity work and Human Survey 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. Human Survey 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 calendar-mcp-2 and sunsiyuan-human-survey 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. Human Survey has 60/100 (Good) with 2 views, 0 installs and 1 GitHub stars.