CalendarMCP vs nspady/google-calendar-mcp: A Real Comparison

The most popular self-hosted Google Calendar MCP server is nspady/google-calendar-mcp. It is open source, runs on your laptop, and works well. CalendarMCP is the hosted alternative.

We get asked which one to pick almost every week. Here is the real answer, from people who would obviously prefer you pick CalendarMCP and still cannot pretend self-hosted is wrong for everyone.

The 30-second answer

• Pick nspady/google-calendar-mcp if you only use Claude Desktop, do not mind a 25-minute setup, and want your Google credentials to never leave your machine.
• Pick CalendarMCP if you use Claude.ai, Claude Code, Cursor, or any HTTP MCP client; want batch operations and multi-calendar support; or have Google Advanced Protection.

Most users land in the second bucket. Plenty land in the first. Both are valid.

What the self-hosted server is good at

The nspady project is a clean, focused implementation. It speaks stdio MCP, uses the standard Google Calendar API, and runs locally. Specifically:

• Your OAuth tokens live in a file on your disk. No third party holds them.
• The code is open source and small enough to read in an afternoon.
• You can fork it and add custom tools, change defaults, or rip out pieces.
• It is free with no rate limits beyond Google's own quotas.
• It works fully offline once tokens are cached.

For a security-conscious solo developer using Claude Desktop, this is genuinely the right answer. We will not pretend otherwise.

Where it gets painful

Setup is a tax

The README walks you through:

1. Creating a Google Cloud project
2. Enabling the Calendar API
3. Creating an OAuth 2.0 desktop client
4. Downloading credentials.json
5. Running an auth flow that opens a browser
6. Saving the resulting token.json
7. Wiring up your Claude Desktop config to point at the binary

This is not hard. It is also 25 to 40 minutes the first time, and most of those minutes are spent in Google Cloud Console, not your terminal.

Stdio means Claude Desktop only

nspady uses stdio MCP, which is great for desktop clients but cannot serve Claude.ai, Claude Code, Cursor, or any web-based MCP client. Those need HTTP. If your workflow uses any of those, self-hosted does not help you without writing a wrapper.

Single calendar, single account

The standard nspady flow connects one Google account at a time. If you have a personal calendar and a work calendar in different Google domains, you have to juggle credentials. CalendarMCP handles this with one API key fanning out across as many connected accounts as you need.

No batch operations

nspady ships per-event tools. To rename twenty meetings, you make twenty tool calls, each round-tripping through Claude. CalendarMCP's batch_update sends the whole set in one call.

OAuth tokens expire weekly without verification

If your OAuth consent screen is in testing mode (which it will be unless you go through Google's verification process), your refresh tokens expire every 7 days. You then re-authenticate. Every week.

Verifying a Google OAuth app is a 1 to 6 week process involving privacy policy review and a security audit. Most self-hosters never bother. They just re-auth every week.

Google Advanced Protection blocks it

Google Advanced Protection is the security mode you turn on if you are a journalist, executive, or activist. It blocks most OAuth apps cold. nspady cannot get past it because it is an OAuth app. CalendarMCP works because it offers a service account flow that does not require OAuth at all.

Feature comparison

The privacy point, fairly

nspady wins on one axis cleanly: your refresh token never leaves your machine. If that matters more than every other feature combined, self-host. We mean it. We have customers who have moved to CalendarMCP for the features and customers who have moved to self-hosted for the privacy posture. Both moves were the right call for that team.

CalendarMCP minimises what we hold (only the Google Calendar scope, nothing else from your Google account), encrypts at rest, and never reads your event content unless you make a tool call. That is genuinely the floor for any hosted calendar service. If your threat model rejects that, you are correct to self-host.

When to switch from self-hosted to hosted

The most common moment users move:

• They start using Claude.ai or Claude Code in addition to Claude Desktop.
• They get tired of the weekly re-auth dance.
• They need to manage 2+ Google accounts at once.
• They run into a calendar task they cannot do without batch operations.

Switching is straightforward. The tools and the prompts your agent uses are similar enough that most workflows port without changes. You revoke the OAuth app in Google account settings, connect CalendarMCP, and update your client config. Twenty minutes of work, including coffee.

Closing

If we were a closed-source service throwing rocks at an open-source project, this would be a different post. We are not. nspady is good. It also has limits that show up the moment your usage grows past a single client. CalendarMCP is the hosted answer for everyone who already hit one of those limits or who would rather not learn where they live.

Pick the tool whose constraints match yours. Either way you have a calendar that talks to your agent in under an hour.