CommsConnector
Google Calendar
List, read, create, update and delete Google Calendar events, with attendees and Meet links, from Claude or ChatGPT through Tulina's own MCP server.
Official site: workspace.google.com/products/calendar
What it can do
2 read/2 write
- 01Read
List the calendars on a Google account
- 02Read
List events over a time range, search them, and read one with its attendees
- 03Write
Create events with guests and a Google Meet link
- 04Write
Update or delete an event
The calendar is the only system that knows a meeting is about to happen. That makes it the natural place to start any workflow whose whole value is being ready before someone walks into a room.
Is there an official Google Calendar MCP server?
Yes. Google documents a Calendar MCP server on calendarmcp.googleapis.com, offered through the Google Workspace Developer Preview Program. You enable the API in a Google Cloud project, create an OAuth client and supply its id and secret to your MCP client. Tulina reaches Google Calendar through its own MCP server instead, with one authorization on your Google account and no Cloud project to set up.
How do you connect Google Calendar to Claude and ChatGPT?
Through Tulina's own MCP server, in three steps:
- In Tulina's Google Calendar connector, choose Authorize Google Calendar. Google asks for the Calendar scope only, on the account you pick.
- Approve it. The tokens stay in Tulina's vault and are never shown to the model.
- Add
https://mcp.tulina.ai/mcpto Claude or ChatGPT and sign in with your Tulina account. The MCP page has the same link.
Several Google accounts can be connected, each named by its address. A request names the account it is for, and an unknown address is refused rather than replaced by another.
Tulina vs Google's Calendar MCP server
Both act on your own calendars. They differ in setup and in what each exposes.
| Google's Calendar MCP server | Tulina | |
|---|---|---|
| Status | Developer Preview | Available now on the connector card |
| Setup | Enable the API in a Cloud project, create an OAuth client | One Authorize button on the connector card |
| Sign-in | OAuth 2.0, per user | OAuth on the Google account, held in Tulina's vault |
| Events | List, search, read, create, update, delete | List, search, read, create, update, delete |
| Scheduling help | Suggest a time, respond to an invitation | Not available |
| In the same conversation | Calendar | Calendar plus your CRM, inbox, meeting notes and the other connected tools |
If Calendar is the only system the model needs, or you want it to suggest times and answer invitations, Google's own server is worth testing once it leaves preview. Tulina earns its place when a meeting is one step in a longer piece of work.
What you can ask it
"What do I have on my calendar tomorrow?" The agent lists events from tomorrow's midnight to the next, ordered by start, and returns each title and time. Narrow it with a search word when you only want one client's meetings.
"Create a follow-up slot on Friday at 10am with the Acme contact, with a Meet link." The agent creates the event with the guest and a Google Meet link. Nobody is emailed unless you ask for invitations to be sent, so a draft slot stays quiet.
"Move Monday's meeting to 3pm." The agent finds the event, then updates only its time. Everything else, such as the guests, the recurrence and the meeting link, is left alone.
Processes use the calendar as their starting point. Prepare for a customer call and Prepare for a demo from the last call read the next meeting and build the brief before it. Calendar pairs with Gmail for the thread behind a meeting and with Granola for the notes after it.
What the Google Calendar connector can't do
- It does not suggest meeting times, check free and busy slots across people, or answer an invitation on your behalf.
- Updating the guest list replaces it, so the agent reads the current guests first and passes everyone. An empty list removes them all.
- Deleting an event is irreversible. Deleting or changing one does not email the guests unless asked.
- It acts on the Google accounts you authorised, with their access. A colleague's calendar is visible only if they shared it with that account.
- It uses Google's Calendar scope, which covers reading and writing. There is no read-only level to choose.
- An all-day event ends on the day after its last day, which is how Google reads the end date.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect Google Calendar once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach Google Calendar at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against Google Calendar returns something usable instead of something generic.
Processes that run on Google Calendar
Prepare for a customer call
Before the call, the last conversations, the account's state, how the product is actually used, and where requested features stand, in one brief.
5 steps →Prepare for a demo from the last call
The last calls, the deal's state and fresh research become one prep brief, plus a deck built on that company's own use cases, posted before the demo.
5 steps →
