Adeu vs Calendar MCP

A side-by-side look at the Adeu and Calendar MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Adeu logoAdeuWorkplace & Productivity · Local subprocess (stdio)docx ↔ LLM translator. Projects .docx office files to Markdown for editing. Projects edits back to OOXML as tracked changes (redlines). Python and Node.js implementations.71GreatAuth: no auth requiredCalendar MCP logoCalendar MCPWorkplace & Productivity · Local subprocess (stdio)Google Calendar for LLM agents: find, create, update, move, delete events; free/busy; scheduling.61GoodAuth: not declared

Verdict: choose Adeu for workplace & productivity work as a local process; choose Calendar MCP 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?

Adeu logoChoose Adeu when

  • You need dedicated capabilities in the Workplace & Productivity domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like accept_all_changes, apply_text_revision, diff_docx_files.
Explore Adeu

Calendar MCP logoChoose 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.
Explore Calendar MCP

Feature & specification comparison

Rows where the two servers differ are marked.

SpecAdeu logoAdeuCalendar MCP logoCalendar MCP
CategoryWorkplace & ProductivityWorkplace & Productivity
Quality signal71/100 · Great61/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNo auth requiredNot declared
PricingFreeNot declared
Required env varsNone listedGOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRET
Verified ownerCommunity listingCommunity listing
GitHub stars16826
Directory activity 7 views 0 installs 0 upvotes 3 views 0 installs 0 upvotes
Tools623

Tools & capabilities

Adeu tools 6

  • accept_all_changesAccepts every tracked change in the document, producing a finalized clean document. remove_comments (boolean, DEFAULT TRUE): also delete every comment. The default is TRUE because this tool's purpose is a distributable clean document, and comments are internal review notes that must not travel to a counterparty. Pass remove_comments=false to accept the tracked changes while KEEPING the comments — use that when the review conversation is still live. Either way the response reports how many comments were deleted and names each one with its author, and comments whose anchored text an accepted deletion consumes are removed regardless, exactly as Word does. [Adeu v3.0.6+df9e00c]
  • apply_text_revisionApplies whole-text revised text to a DOCX document by computing a diff and generating tracked changes. Includes a clean-text verification gate to ensure the applied document matches the supplied text. `revised_text` must be the complete CLEAN view of the document: read it with `read_docx` (`clean_view=true`, `page='all'`), edit that text, and send ALL of it back. Never CriticMarkup ({++, {--, {>>) — this tool diffs against the clean view, so markup tokens would land in the document as literal prose. Never one page of a paginated extract — everything absent from the text is applied as a tracked deletion. INTERLOCK: a revision that drops >50% of the characters (>75% for documents under 2000 characters) is refused unless you pass allow_major_deletions=true. If the applied document's clean text does not then match `revised_text`, NOTHING is written to output_path: a diagnostic copy is kept at <name>.unverified.docx and the call fails. output_path defaults to <name>_redlined.docx; an existing _redlined/_processed artifact is revised in place. [Adeu v3.0.6+df9e00c]
  • diff_docx_filesCompares two DOCX files and returns a compact `@@ Word Patch @@` diff — Adeu's token-level, sub-word patch format — of their text content. Useful for analyzing differences between versions before editing. [Adeu v3.0.6+df9e00c]
  • finalize_documentPrepares a document for external distribution or e-signature. Note: in this zero-dependency environment, protection_mode='encrypt' is unsupported and falls back to a native read-only lock; export_pdf and password are ignored. [Adeu v3.0.6+df9e00c]
  • process_document_batchApplies a batch of edits and review actions to a DOCX. Batches apply SEQUENTIALLY: each change validates against state from prior changes. Valid changes apply when others fail (salvage default): response LEADS with `PARTIAL: applied K of N` listing unapplied changes. Pass partial=false for all-or-nothing. Each item in `changes` needs a `type`: 1. 'modify': search-and-replace. `target_text` must match uniquely (`match_mode`:'strict', default) — add context or set `match_mode`:'first'/'all'. Set `regex`:true for regex matching (groups in `new_text` as $1, $2…). `new_text` supports Markdown: '#'–'######' headings, '**bold**', '_italic_', '\n\n' paragraph split. Omit it (with a comment) to annotate without changing text; empty string deletes. Never write CriticMarkup manually — use `comment`. • EMPTY CELLS: blank cells carry `{#cell:<id>}` anchors — set `target_text` to the anchor and value in `new_text`. Pipes are display separators. 2. 'accept'/'reject': finalize or revert a tracked change by `target_id` (e.g. 'Chg:12'). 3. 'reply': reply to a comment by `target_id` (e.g. 'Com:5') with `text`. 4. 'set_field': fill a form field — `field` is its 'CC:<N>' id, tag or alias, `value` the text; list via `read_docx` `mode`:'fields'. Checkboxes take true/false, dates YYYY-MM-DD, dropdowns a listed option. Dual-writes bound stores. A locked/protected control refuses and names the override permitting it. 5. 'insert_row': add table row — `target_text` anchors on an existing row's text, `cells` holds cell values (left-to-right), `position` is 'above'/'below' (default below). 'delete_row': remove row matching `target_text`. Disk mode only. ID VOLATILITY: 'Chg:N'/'Com:N' ids shift between states — call `read_docx` before accept/reject/reply; never reuse ids from earlier turns. `author_name` sets Track Changes attribution; defaults to 'Adeu AI (TS)' when omitted. [Adeu v3.0.6+df9e00c]
  • read_docxReads a DOCX file. Returns text with inline CriticMarkup for Tracked Changes and Comments: {++inserted++}, {--deleted--}, {==highlighted==}{>>comment<<}. Set clean_view=True for the finalized 'Accepted' text without markup. Modes: - 'full' (default): paginated body content. Use page=N to navigate. - 'outline': heading map only — start here for large docs to plan targeted reads. Defaults to L1-L2 headings; pass outline_max_level=3-6 to see deeper structure. - 'appendix': defined terms, anchors, and cross-reference targets. Consult before editing legal/technical docs to avoid breaking references. - 'changes' (mode='changes'): a ledger of every tracked change and comment (id, type, author, page, snippet) — start here for review work instead of reading pages. Filter with changes_author, page, and changes_offset. - 'fields' (mode='fields'): a ledger of every content control (ordinal, class, alias/tag, location, lock/binding state, current value) — start here to discover fillable fields. Paginate with fields_offset; `page` and `search_query` do not apply. `page`: a positive integer (1-indexed, default 1), a page RANGE like '2-6' (returns up to 8 pages in one call, then names the next range), or 'all'. Pages are synthetic length-based chunks sized for LLM consumption, NOT printed Word pages. In mode='full', page='all' returns the whole body with no page chrome; oversized documents are refused with an outline and a bounded-read recipe unless force=true. With `search_query`, `page` instead restricts matches to that page (default: search all pages). [Adeu v3.0.6+df9e00c]

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

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.

Adeu

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "adeu": {
      "command": "npx",
      "args": [
        "-y",
        "@adeu/mcp-server"
      ]
    }
  }
}

Calendar MCP

mcpServers (Claude Desktop / Cursor)
{
  "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"
      }
    }
  }
}

Frequently asked questions

Adeu is categorized under Workplace & Productivity and uses a local stdio subprocess. Calendar MCP belongs to Workplace & Productivity and uses a local stdio subprocess. Pick Adeu for workplace & productivity work and Calendar MCP 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.

Adeu is listed as free. Auth: no auth required. Calendar MCP 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 adeu and calendar-mcp-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Adeu has a quality signal of 71/100 (Great) with 7 views, 0 installs and 168 GitHub stars. Calendar MCP has 61/100 (Good) with 3 views, 0 installs and 26 GitHub stars.