How to connect a Google Calendar MCP to Cursor (4 steps)

Developers building scheduling tools, meeting bots, or calendar sync applications on top of Google Calendar need to understand the API's data model while writing the integration code.

What fields does an event object return, and which are optional? How does the attendees array differ between a recurring event instance and its parent? What timezone format does the API use in start.dateTime, and how does that differ from an all-day event's start.date?

Without an MCP connection, answering those questions means leaving Cursor, setting up OAuth credentials separately, running test calls against the Calendar API, and copying response JSON back into the session where the integration code is being written.

To help your developers access and query calendar data without leaving Cursor, we'll show you how to connect Google Calendar with Merge Agent Handler's Google Calendar MCP server.

How it works

Merge Agent Handler connects Cursor to the Google Calendar API through the Merge CLI.

Install the CLI, authenticate once, and run a single setup command from your project root. That command writes a ## Merge CLI section to the project's .cursorrules file, which tells Cursor's agent when to call merge search-tools and merge execute-tool to reach Google Calendar.

Once connected, Merge handles Google's OAuth token storage and refresh so you never configure a Cloud project or manage credential rotation in your local environment.

Here's the registration command:

merge setup cursor

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Cursor installed
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Google account with access to the calendars you want to query

If you want to connect Merge Agent Handler's Google Calendar MCP with internal or customer-facing agentic products, you can follow the steps in our docs.

1. Install the Merge CLI

Run the following to install the Merge CLI: pipx install merge-api

Verify your installation: merge --version

Related: How to use the Google Calendar MCP in Claude Code

2. Log in to Merge

Authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your account so it can make authorized requests to Google Calendar on your behalf.

3. Connect the CLI to Cursor

Run the following from the root of the project where you want to use Merge tools:

merge setup cursor

This writes a ## Merge CLI section to .cursorrules so Cursor knows to use the CLI for third-party services. The command is idempotent, safe to re-run if you need to reset.

4. Authenticate Google Calendar

Open a Cursor chat in your project and start with a query that reflects real integration work. For example: "List all calendar events for a given user in the next 7 days, including the event ID, summary, start and end times, attendees, and recurrence fields, so I can write correct normalization logic for my calendar sync integration."

The first time you invoke a Google Calendar tool, a Magic Link will appear to complete connector authentication.

{{this-blog-only-cta}}

Google Calendar MCP FAQ

In case you have more questions on setting up and using the Google Calendar MCP in Cursor, we've addressed several more commonly-asked questions below.

What can you do once the Google Calendar MCP is connected to Cursor?

With Google Calendar connected, Cursor can:

• Inspect event object field shapes before writing a normalization layer: fetch a real event response to see which fields are always present, which are optional, and how the API represents recurring instances vs. their parent rules, before writing the code that maps calendar data to your internal schema

• Check how all-day vs. timed events differ in the API response before writing date-handling logic: retrieve both event types from a real calendar to confirm whether the field is start.date or start.dateTime before writing the conditional that handles each case in your parser

• Fetch calendar list metadata before writing a multi-calendar aggregation function: retrieve the calendars accessible to an account, including their IDs, access roles, and time zone settings, before writing the function that queries across multiple calendars and merges their event streams

• Retrieve recurrence rule formats before writing expansion logic: pull recurring events to see the exact RRULE string format the API returns before writing the code that expands recurrence rules into individual event instances

• Inspect attendee response status fields before writing RSVP-based logic: fetch an event with multiple attendees to see the exact structure of the attendees array and what values the responseStatus field takes, before writing code that filters or routes based on acceptance state

• Validate pagination behavior before writing a full event sync loop: fetch a time range that returns multiple pages of results to see how the API surfaces the nextPageToken field and when it stops appearing, before writing the pagination loop your sync job depends on

Why use Merge Agent Handler vs. a self-hosted Google Calendar MCP server?

You can connect directly to the Google Calendar API by setting up a Google Cloud project, configuring OAuth credentials, and pointing your own MCP server at the Calendar API. For a single developer working against their own calendar, that setup is feasible and the documentation is thorough.

The credential management problem appears as soon as more than one developer or agent is involved.

OAuth tokens issued through a personal Google Cloud project carry the permissions of the account that granted them. Sharing credentials across agents or team members means every agent reaches every calendar the account can see, with no mechanism to restrict which users' calendars a given agent can query. Token rotation requires updating every system that holds the credential at once.

Merge Agent Handler handles Google OAuth centrally.

You define exactly which Calendar operations each agent is allowed to call: an agent that reads event data to power a scheduling assistant can reach read tools without touching write operations like creating or deleting events. Every call is logged with the timestamp, tool, and inputs, so you have a full audit record of which calendar data each agent accessed and when.

For teams building calendar integrations that will eventually run against real user calendars at scale, that combination of scoped access and centralized logging is the difference between a deployment you can reason about and a shared credential problem.

Why connect Google Calendar to Cursor?

Google Calendar's API has a data model that only makes full sense once you've seen a real response.

The documentation describes the event object, but it doesn't show you which fields are omitted when there are no attendees, how the API encodes the time zone difference between an all-day event and a timed one, or what the pagination token looks like on the last page of results.

Those details determine whether the integration code you write handles edge cases correctly or fails silently on real data.

Connecting Google Calendar to Cursor puts that reference data in the same session where the integration is being written.