All documentation
On this page

For administrators

For Google Workspace admins

Somebody in your organisation wants to connect their own Gmail mailbox, or its calendar, to an AI assistant through this service. For Gmail there is nothing for you to approve. For the calendar there is one OAuth app, and this page gives you its client ID, its 3 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, and 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 2 separate connections, and they work differently. Mail is reached over IMAP with an app password the user creates in their own Google Account, so there is no OAuth app involved and nothing for an administrator to allowlist. The calendar is a separate, optional step made through Google's own sign-in, with an OAuth client that asks for 3 calendar scopes and nothing else. Each connection belongs to the user who made it and reaches only their own account.

Gmail needs nothing from you

The user turns on 2-Step Verification in their Google Account, creates an app password at myaccount.google.com/apppasswords, and pastes 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. An app password is independently revocable by the user, 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:

  • 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 an account under the Advanced Protection Programme, and a work, school or other organisation account, as the other 2 reasons, without naming the setting behind the last one.
  • 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 calendar 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 nameMailbox MCP
OAuth client ID374687245895-r3o0bmuvskvnq3l2prfutmco947u4tpe.apps.googleusercontent.com
DeveloperBSolve IT Limited, company 04607330, England and Wales
VerificationApproved by Google on 4 September 2026 for the one sensitive scope it asks for, so users see no "unverified app" screen.
Redirect URIhttps://app.mailbox-mcp.com/mailboxes/google-calendar-callback/
Scopes3, all on Google Calendar. No Gmail, Drive, Contacts or directory scope.

The 3 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.googleapis.com/auth/calendar.events 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.googleapis.com/auth/calendar.events.freebusy 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.googleapis.com/auth/calendar.calendarlist.readonly 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.

Google classifies calendar.events as a sensitive scope and the other 2 as not, which is why the verification review named only the first. 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.

Mark it Trusted

Whether your users can complete the calendar 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, and the app has to be configured by hand.

  1. 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.

  2. 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.

  3. 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 3 calendar 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. Nothing is connected by the setting itself, and each user still signs in as themselves and approves the 3 scopes on Google's own screen.

What it never does

  • Never

    Reach Gmail through the calendar app

    The OAuth client asks for 3 calendar scopes and no others, and Google shows the user that list before they approve it. Mail on the same account is a separate connection by app password, made by the user, and the calendar grant gives no access to it. There is no Drive scope, no Contacts scope, and no directory access of any kind.

  • Never

    Act without 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, and the app cannot open a calendar or a mailbox whose owner has not connected it. Marking it Trusted changes what your users may approve; it gives the app nothing on its own.

  • Never

    Store mail or events

    Messages and events pass through in memory on each request and are not written to disk. What is stored is the app password and the calendar token, envelope encrypted, and 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 data, and 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 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 as needing reconnecting, tells its owner once, and does nothing else with it.

The calendar 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 from their own control panel, which deletes the token we hold. 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, and 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. Mail on a Google account is reached over IMAP with an app password the user creates in their own Google Account, so there is no OAuth client for Gmail, no Gmail scope, and nothing to configure under Manage App Access in the Admin console. What has to be true at your end is ordinary: 2-Step Verification allowed for the user's organisational unit with a phone or an authenticator app as a permitted second step, since Google offers no app passwords to an account set up only for security keys, and IMAP switched on under Apps, Google Workspace, Gmail, End User Access. Only the calendar has an OAuth app to approve.

Which Google scopes does the Mailbox MCP calendar app ask for?

3, all on Google Calendar: calendar.events, calendar.events.freebusy, calendar.calendarlist.readonly. Google classifies calendar.events as sensitive and approved the app for it on 4 September 2026, so users see no unverified-app screen. There is no Gmail, Drive, Contacts or directory scope, and the app cannot reach a scope it does not request. 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?

Because the Admin console's app access controls refused the consent: either unconfigured third-party apps are limited to basic sign-in information or not allowed at all, or Google Calendar is marked as a restricted service, or the app has been configured as Limited or Blocked. The fix is to configure the app by its client ID under Security, Access and data control, API controls, Manage App Access, and set it to Trusted for the organisational units that need it. Limited allows only unrestricted services, so with Calendar restricted it produces the same refusal.

How do I revoke the Mailbox MCP calendar app for my organisation?

On the same Manage App Access screen, change the app from Trusted to Blocked, which Google defines as unable to access any Google data; Google then refuses its requests for your users' calendars and no new consent succeeds. A single user can remove the app under third-party apps at myaccount.google.com/permissions, or remove the calendar from their control panel, which deletes the token held for it. Gmail is ended by the user deleting the app password or removing the mailbox, or by you turning 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.

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.