Google Calendar MCP Server: OAuth Is the Hardest Part
Google Calendar MCP Server: OAuth Is the Hardest Part
Building an MCP server for Google Calendar sounds like a weekend project. The Calendar API is well documented. The MCP protocol is simple. You wire up a few tools - create event, list events, update event - and you are done.
Except you are not done, because OAuth exists.
The OAuth Problem
MCP servers run as background processes. They do not have a browser. They do not have a UI. But Google OAuth requires opening a browser, logging in, granting consent, and redirecting back to a callback URL.
You need to handle the initial authorization flow, token storage, token refresh, and the edge case where refresh tokens expire after six months if your app is in testing mode. Every single one of these steps has failure modes that are silent and confusing.
What Actually Works
The most reliable approach is separating the auth flow from the MCP server itself. Run a one-time setup script that opens the browser, completes OAuth, and saves the tokens to a file. Then your MCP server reads the tokens on startup and refreshes them as needed.
Trying to do the OAuth flow inside the MCP server itself - launching a browser from a stdio process, handling the callback - is fragile and platform-dependent.
The Token Storage Question
Where do you store tokens? A JSON file in the user's config directory works but is not encrypted. The macOS Keychain is more secure but adds complexity. Whatever you choose, make sure token refresh happens transparently. The worst user experience is having your calendar tools randomly stop working because a token expired.
The calendar integration itself is the easy part. Spend your time getting auth right.
Fazm is an open source macOS AI agent. Open source on GitHub.