All documentation
On this page
For administrators
For Google Workspace admins
Somebody in your organisation wants to connect their own Gmail mailbox, its calendar or their Google contacts to an AI assistant through this service. For Gmail there is nothing for you to approve. For the calendar and the contacts there is one OAuth app, and this page gives you its client ID, its 4 scopes, the Admin console setting that allows it, and the way to revoke it.
What it is
Mailbox MCP is a hosted MCP server. A person connects a mailbox they already own to it. An AI assistant they already use (Claude, ChatGPT, Cursor and others) can then read and act on that mailbox through the Model Context Protocol, the open standard those assistants use to reach outside tools.
The service is run by BSolve IT Limited, a company registered in England and Wales, number 04607330. What it does in full is on how it works; what it holds and how that is protected is on the security page.
On a Google account it makes up to 3 separate connections, and they work differently. Only the calendar and the contacts involve an OAuth app, and it is one app.
| Connection | How it is made | The app involved |
|---|---|---|
| Over IMAP, with an app password the user creates in their own Google Account. | None. No OAuth app, so nothing to allowlist. | |
| The calendar | A separate, optional step made through Google's own sign-in. Its consent asks for 3 calendar scopes and nothing else. | The OAuth app below. |
| Google contacts | Another optional step through the same OAuth client, in a consent of their own. It asks for the contacts scope and nothing else from Google's APIs, beside the user's email address. | The same OAuth app. |
Each connection belongs to the user who made it and reaches only their own account.
Gmail needs nothing from you
The user does it all in their own Google Account. They
turn on 2-Step Verification, create an app password at
myaccount.google.com/apppasswords, and paste it into the
control panel. The service signs in to imap.gmail.com and
smtp.gmail.com with that password, over TLS, as that user.
Google's own words on the mechanism: "App passwords can only be used with accounts that have 2-Step Verification turned on."
There is no OAuth client for Gmail on our side, no Gmail scope, and no entry for you to make in the Admin console's app access list. The user can revoke an app password on its own, without changing their Google password.
What can stop it is at your end, and both are ordinary Admin console settings rather than anything specific to this service:
-
Setting 1
2-Step Verification
Under Security, then Authentication, then 2-step verification, the user's organisational unit has to be allowed to turn it on.
Google's app passwords page lists 2-Step Verification "set up only for security keys" as a reason the app password option is missing. So an enforcement of Only security key leaves those users without one. A phone or an authenticator app as a permitted second step is what makes the option appear.
The same page lists 2 other reasons: an account under the Advanced Protection Programme, and a work, school or other organisation account. It does not name the setting behind the last one.
-
Setting 2
IMAP
Under Apps, then Google Workspace, then Gmail, then End User Access, IMAP has to be on for the user's organisational unit.
If you have restricted IMAP to specific OAuth-compliant mail clients by client ID, an app password sign-in is not one of those clients, and will be refused. The setting that works is to allow any mail client.
Nothing about IMAP in the user's own Gmail settings
Google removed the Enable IMAP and Disable IMAP options from a user's Gmail settings in January 2025. IMAP is always on for the account unless your Admin console turns it off, so if a user cannot connect, the switch is yours rather than theirs.
The Google calendar and contacts app, by its identifiers
These are the values to check against what your user, or the app access list in your Admin console, is showing you. If the client ID differs, it is not this app.
| Consent screen name | Mailbox MCP |
| OAuth client ID | 374687245895-r3o0bmuvskvnq3l2prfutmco947u4tpe. |
| Developer | BSolve IT Limited, company 04607330, England and Wales |
| Verification | Approved by Google for each sensitive scope it asks for (calendar.events on 4 September 2026 and contacts on 24 September 2026), so users see no "unverified app" screen. |
| Redirect URI | https://app. |
| Scopes | 4: 3 on Google Calendar, asked for by the calendar consent, and 1 on Google Contacts, asked for only by the contacts consent. No Gmail, Drive or directory scope. |
The 4 scopes
Google's description is Google's own wording for each scope, which is also what the consent screen shows your user.
| Scope | Google's description | What it is used for |
|---|---|---|
https://www. Sensitive |
View and edit events on all your calendars | The calendar: listing, reading, creating, moving and cancelling events, and sending and answering invitations, in the calendars the signed-in account can already reach. |
https://www. |
See the availability on Google calendars you have access to | Free and busy time, so a meeting slot can be found without reading the events that make a period busy. |
https://www. |
See the list of Google calendars you're subscribed to | Which calendars the account has, so the assistant can name the right one and never guess. |
https://www. Sensitive |
See, edit, download, and permanently delete your contacts | Google contacts, where the owner has connected them to a mailbox in a consent of their own: finding a person, reading a card, creating, correcting, deleting and importing contacts. Never asked for by the calendar consent. |
Google classifies calendar.events and contacts as sensitive and the other 2 as
not, which is why each of those went through its own verification
review. Free and busy time is asked for separately, as its own scope,
so a meeting slot can be found without the assistant reading the events
that make a period busy. The contacts scope is the only one that
reaches the user's Google contacts, and the calendar's consent never
asks for it.
Mark it Trusted
Whether your users can complete the calendar or the contacts connection depends on the Admin console's app access controls, under Security, then Access and data control, then API controls.
If unconfigured third-party apps are set to "Allow users to access any third-party apps", which is Google's default, the connection works and there is nothing to do.
If they are limited to basic sign-in information, or not allowed at
all, or if you have marked Google Calendar as a restricted service, the
user meets Google's refusal, admin_policy_enforced. Then the
app has to be configured by hand, in 3 steps.
-
Open the app access list
Security, then Access and data control, then API controls, then Manage App Access. Google's current help page calls the button that; older write-ups, including the note our control panel gives your user to forward, call it Manage third-party app access. Same screen.
-
Configure new app, and search by the client ID
Choose Configure new app, paste the client ID from the table above into the search, and select Mailbox MCP from the result. Searching by ID rather than by name is what guarantees you are configuring this app and not another with a similar name.
-
Choose the organisational units, then Trusted
Scope it to the whole organisation or to the units that need it, set the access to Trusted, and finish. Google defines Trusted as "Can access all Google services (both restricted and unrestricted)", which for this app means the 4 calendar and contacts scopes it asks for and nothing else, because an app cannot reach a scope it does not request.
Why Limited is not enough
Google defines Limited as "Can only access unrestricted Google
services". If Google Calendar is marked restricted in your console, a
Limited app is refused the calendar scopes and the user sees exactly
the same admin_policy_enforced error as before you
configured it. Trusted is the setting that works whichever way
Calendar is marked.
Once it is Trusted, the user goes back to the control panel and connects the calendar or the contacts. Nothing is connected by the setting itself, and each user still signs in as themselves and approves the scopes that consent asks for on Google's own screen.
What it never does
-
Never
Reach Gmail through the calendar or contacts app
The OAuth client asks for 3 calendar scopes in the calendar's consent and the contacts scope in the contacts consent, and no others. Google shows the user each list before they approve it.
Mail on the same account is a separate connection by app password, made by the user, and neither grant gives any access to it. There is no Gmail scope, no Drive scope, and no directory access of any kind.
Google contacts are asked for only when the user presses Connect Google contacts in the control panel. A Gmail mailbox without them resolves the people it writes to from its own history, or from an address book its owner connects at a CardDAV server elsewhere, on the user's own credential for that server.
Google's auto-collected "Other contacts" have a scope of their own, which is never asked for.
-
Never
Act as anyone but the user
There is no service account and no domain-wide delegation. Every request is made as the user who signed in, with a token scoped to what they approved. The app cannot open a calendar or a mailbox whose owner has not connected it.
A routine the user sets up in their own Claude or ChatGPT, which can run on a schedule while they are away, is no exception: it works through the user's own connections, as them.
Marking it Trusted changes what your users may approve; it gives the app nothing on its own.
-
Never
Store mail, events or contacts
Messages, events and contacts pass through in memory on each request and are not written to disk. A contact is held in memory for about 10 minutes, then forgotten.
What is stored: the app password, the calendar token, and the contacts token where the user has connected Google contacts (or, instead, the address and credential of an address book at a CardDAV server elsewhere), each envelope encrypted. Plus one log line per call, naming the tool and the time.
The privacy policy states the mechanisms and carries Google's Limited Use disclosure for the calendar and contacts data. The threat model says what an attacker can and cannot do with the arrangement.
-
Never
Anything the user did not choose
A connection belongs to the person who made it, and that person also picks how much their AI client may do with it: read only, draft and file, or send and delete, with the calendar as a separate switch. The server enforces that level on every call, before the AI client is consulted. What you can limit describes it.
Revoke it
The calendar and contacts app, for the organisation. On the same Manage App Access screen, change Mailbox MCP from Trusted to Blocked, which Google defines as "App can't access any Google data". Google then refuses the app's requests for your users' data and no new consent succeeds. The control panel marks each affected calendar or contacts connection as needing reconnecting, tells its owner once, and does nothing else with it.
The calendar and contacts app, for one person. The
user opens myaccount.google.com/permissions, finds
Mailbox MCP under third-party apps and removes its
access, or removes the calendar, or disconnects the address book, in
their own control panel,
which deletes the token we hold and hands the permission back to
Google. Either ends it that minute.
Gmail. The user deletes the app password at
myaccount.google.com/apppasswords, or removes the mailbox
from their control panel. From your side, turning IMAP off for the
organisational unit, or requiring a second step the app password route
cannot satisfy, ends every such connection at once, along with every
other IMAP client those users have.
Questions
Write to support@mailbox-mcp.com. Questions from administrators are answered by the person who built the service. If your organisation needs a security questionnaire answered before it will trust a third-party app, send it.
The security page, the threat model and the privacy policy are where most of the answers already are, and the changelog records every change to what a connected client can do.
If your organisation is on Microsoft 365 instead, or on both, the Microsoft 365 page carries that app's identifiers, its delegated permissions and the link that approves it for the whole tenant in one step.
Frequently asked questions
Does a Google Workspace administrator need to allowlist Mailbox MCP for Gmail?
No. Gmail is reached over IMAP with an app password the user creates, so there is no OAuth client for Gmail and nothing to configure under Manage App Access. At your end: 2-Step Verification allowed for the user's organisational unit, with a phone or an authenticator app as a permitted second step, and IMAP on under Apps, Google Workspace, Gmail, End User Access. Only the calendar and Google contacts have an OAuth app, and it is one app.
Which Google scopes does the Mailbox MCP app ask for?
4 in all: calendar.events, calendar.events.freebusy, calendar.calendarlist.readonly, contacts. The calendar consent asks for the calendar scopes and the contacts consent for the contacts scope, each when the user connects that one. Google classifies calendar.events (approved 4 September 2026) and contacts (approved 24 September 2026) as sensitive and approved the app for each, so users see no unverified-app screen. There is no Gmail, Drive or directory scope. The OAuth client ID is 374687245895-r3o0bmuvskvnq3l2prfutmco947u4tpe.apps.googleusercontent.com, and the consent screen names the app Mailbox MCP.
Why does a Google user get admin_policy_enforced when connecting a calendar to Mailbox MCP?
The Admin console's app access controls refused the consent: unconfigured third-party apps are limited to basic sign-in information or not allowed, Calendar is a restricted service, or the app is configured as Limited or Blocked. Fix it under Security, Access and data control, API controls, Manage App Access: configure the app by its client ID and set it to Trusted for the units that need it. Limited allows only unrestricted services, so with Calendar restricted it fails the same way.
How do I revoke the Mailbox MCP app for my organisation?
On Manage App Access, change the app from Trusted to Blocked, which Google defines as unable to access any Google data. Google refuses its requests for your users' calendars and contacts, and no new consent succeeds. One user can remove the app at myaccount.google.com/permissions, or remove the calendar or disconnect the address book in their control panel. Gmail ends when the user deletes the app password or removes the mailbox, or when you turn IMAP off for their organisational unit.
Sources
Every statement above about Google Workspace was read off one of these pages on . The app's own identifiers were read out of the production service configuration the same day, and Google's approval of the sensitive scope is recorded in the server repository's status log against the day it arrived.
- Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data The API controls path, the Manage App Access button, the definitions of Trusted, Limited and Blocked, restricted and unrestricted services, and the 3 settings for unconfigured apps.
- Google Account Help: Sign in with app passwords That app passwords need 2-Step Verification, and the 3 reasons the option can be missing, quoted above.
- Google Workspace Admin Help: Turn POP and IMAP on or off for users The End User Access path, and the option to restrict IMAP to specific OAuth mail clients, which an app password sign-in does not satisfy.
- Google Workspace Admin Help: Deploy 2-Step Verification The Authentication path and the enforcement options, including Only security key.
- Google: OAuth 2.0 Scopes for Google APIs Google's own one-line description of each of the 4 scopes, reproduced in the table; the contacts row read again on 24 September 2026.
- Mailbox MCP: Connect a Gmail mailbox The user's side of the same connection: the app password steps, the passkey dead end, and the calendar and Google contacts sections.
Read 13 September 2026 Every Google Workspace fact on this page was read off the Google help pages listed under Sources on that day. If it has changed since, tell us and we will read it again.