What Gmail and Calendar MCP access for ChatGPT takes
The ask usually starts with one person who tried it alone and wants it for everybody. Gmail and Calendar MCP access for ChatGPT, given to a whole team, takes three things. The Elaichi app added once in ChatGPT. A Gmail and a Google Calendar connection owned by each person. Restrictions on the role those people hold.
Elaichi serves MCP at one address, https://api.elaichi.ai/mcp. ChatGPT reaches it there. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The same address serves every organization. Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL.
In Elaichi's catalog, Google Workspace is not a single connector. Gmail and Google Calendar are separate, as are Google Drive and Google Docs. The catalog also carries a googleworkspace connector under its sso category. A rule written on Gmail therefore says nothing about Calendar. Write both.
Who adds the app in ChatGPT, and who signs in afterward
A ChatGPT admin or owner adds Elaichi once, as a custom MCP app. Everyone else then signs in to it as themselves.
OpenAI says full MCP support in ChatGPT, including modify and write actions, is rolling out in beta to the Business, Enterprise and Edu plans. On Business, only admins and owners can enable developer mode and deploy a custom MCP app (checked October 2026, OpenAI's developer mode and MCP apps page). Admins and owners create the app at Workspace settings to Apps to Create. The form takes the server endpoint and metadata, an authentication mechanism, a Scan Tools step, the authorization prompt, then Create. Publishing runs through Workspace settings to Apps to Drafts to Publish. The app then shows in members' Apps settings with the label custom (checked October 2026).
Two things to plan around. On Business, OpenAI's page says admins cannot enable developer mode for individual members of their workspace. On Enterprise and Edu, admins can use role-based access control to give developer mode to selected members (checked October 2026).
Google's side is administered separately. Workspace admins manage third-party app access in the Google Admin console, under Security, then Access and data control, then API controls, then Manage App Access (checked October 2026, Google's guide to controlling which apps reach Workspace data).
To ChatGPT, Elaichi is one app for the whole organization. Connected tools arrive through it, and connected tools are never listed one by one, however few there are, so ChatGPT finds Gmail and Calendar tools by searching. The screen-by-screen version is in the ChatGPT setup walkthrough.
Why one shared Gmail connection is the wrong shape for a team
Every call through a connection runs on the account that authorized it, whoever is calling. Share one person's Gmail connection with the team and every teammate's ChatGPT reads that person's mail.
Mail and calendars are the clearest case for per-person identity, the same shape as giving each person their own Dropbox connection. Each person connects Gmail and Google Calendar with their own Google sign-in. Their own Google permissions then apply to their own calls.
To save them the setup, build a template and share it at use. A template is a named list of tool entries, and it stores no connection. Each person stamps their own toolbox from it and picks their own connection for each connector. A toolbox shared with a team does not do this, because its entries run on the connection pinned in them. Agent access that matches each employee's permissions covers the pattern in full.
Restriction one: block the Gmail tools that send, reply and delete
The failure everyone pictures is an AI sending mail. One restriction stops it. A restriction is a rule saying which connectors and tools a role, or one member, may reach.
You need the rule because of how consent works. On Elaichi's consent screen, "Run your connected tools" covers every tier of connected tool, writes and deletes included. "Delete data and remove access" covers Elaichi's own deletes, not Gmail's. No consent checkbox holds a client to reading a connected app.
ChatGPT's own permission setting does not close it either. On a Pro account on 2026-10-15, the plugin settings page offered Refresh tools and a Permission choice of Always ask, Allow read-only tools, Allow low-risk tools by default, and Allow all tools. For write or modify actions, ChatGPT may ask for confirmation, depending on app permissions and the action's context (checked October 2026, OpenAI on managing app permissions in ChatGPT). None of the Elaichi tools that run connected tools is marked read-only. A setting that lets read-only tools run unprompted will therefore still prompt on every connected-app call, reads included, and it makes nothing read-only.
So write the rule in Elaichi. Open the gmail connector and read its tool list. Anyone holding the Browse connectors permission sees every tool, each flagged whether it is restricted for them. Note every tool that sends, replies, forwards or deletes, and name those tools in a block rule on the role. A block rule matches by name or by operation, so renaming a tool later does not slip it past the block. Allow rules match the stored operation only, an asymmetry explained in why blocks catch renamed tools.
Name the trade-off. A layer with only block rules has no allowlist, so any tool no rule mentions stays reachable. An allow rule naming just the read tools closes that gap. But once a role carries any allow rule, every connector none of its allow rules names is blocked for that role. If the team also uses Jira or Slack, that role needs whole-connector allow rules for them too.
One more argument for blocking the send path. An email body can carry instructions aimed at the model. Elaichi's MCP endpoint inspects no tool result for that, and nothing there could: a tool call carries a tool name and arguments, never the person's own typed request, so there is nothing to judge the call against. That defense belongs to the client.
Restriction two: keep calendar changes with the role that needs them
Keep calendar writes with the one role that needs them, and block them everywhere else. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.
Decide which role may change a calendar. If a scheduler or an executive assistant should create and cancel events and nobody else should, those people need a role of their own. Custom roles need the role:manage permission, and Gold includes them. A member holds exactly one role, so a custom role has to carry everything that person needs, not only the extra.
A rule aimed at one member sits on a second layer. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
Timing matters when you roll this out. Changes to roles, team membership and restrictions reach every surface within about two minutes. Revocation is different: a disconnected or revoked grant fails the client's very next call.
Restriction three: block the connector outright where the team should not have it
Some roles have no business in mail at all. For them, block the gmail connector whole, which blocks every tool on it. An allow rule naming a connector whole does the inverse and admits every tool on it.
Two limits matter here. A restriction binds a connector's own identity, its slug and its declared fork lineage, never the host it calls. A connector built from scratch against the same API is not caught by that block, which is why connector:create is the one permission Elaichi flags as high trust.
The second limit is that a blocked tool is not invisible. Search names it, flagged restricted and with no schema. A refused call tells the caller the tool is restricted for their role and that an admin can lift it. From the client, that person can file their own access request. Only an admin can approve it, in the console, under Governance to Access requests.
The audit query that proves the restrictions held
Open the audit log, set the category filter to Assistant, set the date range, and search for gmail. Connected-tool calls, ChatGPT's included, sit in the Assistant category, because their action is assistant.toolbox_tool. The MCP category holds grant events, not tool calls.
The free-text search matches each word anywhere in the action, resource type, resource id, acting user id and the event's metadata. So the connector's name finds its calls. The console offers four date ranges: All time, Last 24 hours, Last 7 days and Last 30 days.
Each connected-tool row records:
- who called, and the toolbox the call went through
- the tool's advertised name and its catalog name
- the connector and the connection the call reached
- the tool's classification, and how approval was given
- the surface, and the MCP client when the surface is mcp
- what the call touched, and whether it worked
ChatGPT is one of seven clients whose name Elaichi can show as verified, matched from the redirect addresses it registered. Other clients show the name they gave themselves. In a row's detail panel, the line that settles the question is "What it did", which reads Read data, Changed data or Deleted data. Thirty days of Gmail rows that all read Read data is your evidence.
Know what the query cannot show. A call a restriction withholds writes no audit row, because the refusal happens before anything executes. The record that the rule exists is the restriction.created or restriction.updated entry in the same log. Pair the two. What an AI agent audit log has to capture goes deeper on the fields.
Three practical notes. Reading the whole organization's log needs the audit:view permission, held by Org Owner, Org Admin and Auditor; everyone else reads their own events. Auditor is a free seat, so a compliance reviewer takes no billable seat. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. The CSV export applies the current filters and stops above 10,000 entries.
When you do not need any of this
If two people want their own mail in their own chat, and nobody is asking who did what, you do not need a control plane. Let them connect through whatever your ChatGPT workspace already offers, and stop there.
The case for this setup begins when more than one app and more than one team are involved. One address, one set of rules, one log, and one action that cuts a leaver off. Removing or suspending a member revokes their grants, and their ChatGPT connection fails on its next call.
Where to go next
Up to the broader picture: how MCP governance is layered. Across: restricting ChatGPT Enterprise connectors and choosing between a tool-level and an app-level rule. Out to the connector catalog and the governance use cases.
