For administrators

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.

For a Microsoft 365 mailbox the connection is one Microsoft sign-in. The user is sent to Microsoft, signs in as themselves, and Microsoft asks them to grant the app a short list of delegated permissions on their own mailbox. The user consents for their own mailbox only. The app then acts as that signed-in user, with that user's rights and no more, and nothing about the grant reaches any other mailbox in your tenant. If your tenant's policy does not let users grant those permissions themselves, Microsoft shows them "Need admin approval" instead, which is how you come to be reading this.

The app, by its identifiers

These are the values to check against what your user, or the consent request in your admin centre, is showing you. If the application ID differs, it is not this app.

The 5 delegated permissions

All 5 are delegated: each works only while a user is signed in, and only as that user. Nothing on this list can run without a person.

None of the 5 requires admin consent in Microsoft's own classification: that is the value in the Admin consent required column of the app registration for each of them, and it is why a user in a tenant on Microsoft's default consent setting, "Allow user consent for apps", grants them alone and never reaches you. It is not the same as saying every tenant lets them. A tenant on the setting Microsoft recommends allows users to consent only to permissions its administrator has classified as low impact, and none of these is in Microsoft's suggested low-impact set, so on that setting the user meets the approval screen instead. The section on blocked consent below says what to do about it.

One thing the list does not need, and it is worth knowing because it is the step that usually needs an IT department: sending goes through Microsoft Graph, not SMTP, so Authenticated SMTP stays switched off on the mailbox and on the tenant.

What it never does

• Never

  Application permissions

  There are none. No client credentials flow, no app-only token, no permission that works without a signed-in user. Nothing this app holds can open a mailbox whose owner has not signed in and consented, and a tenant-wide grant does not change that: it only removes the prompt each user would otherwise see.

• Never

  Tenant-wide reading, or the directory

  It cannot list your users, read a mailbox nobody connected, or see who else is in the tenant. It asks for no directory permission of any kind, and every permission above is scoped to the signed-in user's own mailbox, calendar and mailbox settings. Nothing in Exchange is configured by connecting: no transport rule, no mail flow connector, no delegation.

• Never

  Mail stored on our side

  Messages pass through in memory on each request and are not written to disk. What is stored is the token Microsoft issued, envelope encrypted, and one log line per call naming the tool and the time, never the contents of a message. The privacy policy states the mechanisms, and the threat model says what an attacker can and cannot do with the arrangement, row by row.

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

Approve it once for everyone

The link below is Microsoft's tenant-wide admin consent URL for this app, in the form Microsoft documents: login.microsoftonline.com/organizations/adminconsent with the application ID above. It asks for every permission in the app's registration at once, which for this app is the 5 delegated permissions in the table and nothing else. Read the address before you sign in; a consent link should never go anywhere but login.microsoftonline.com.

Who can press it. Microsoft requires a Privileged Role Administrator, or a Cloud Application Administrator, AI Administrator or Application Administrator, for an app that asks for delegated permissions and no Microsoft Graph application permissions, which is this app. A Global Administrator holds all of those.

What the screen shows. Microsoft's own consent prompt, with the verified publisher and the 5 permissions listed by their plain descriptions. Accepting it consents on behalf of your organisation. Microsoft then returns the browser to https://app.mailbox-mcp.com/mailboxes/microsoft-callback/ with admin_consent=True, and that page confirms the approval and asks for nothing more. The tenant ID Microsoft includes in that return is not used for anything: Microsoft warns against trusting it, and nothing about your tenant is stored by the return.

What changes afterwards. The app appears in your admin centre under Enterprise applications, with the 5 permissions granted for all users. People in your tenant who connect a mailbox no longer see a consent prompt; they still sign in as themselves, still choose which mailbox, and still connect only their own. Nothing is connected by the approval itself. The person who asked you goes back to the control panel and finishes.

If your policy blocks user consent

Your user saw "Need admin approval" because of one setting: User consent for applications, under Enterprise apps, Consent and permissions, User consent settings in the Microsoft Entra admin centre. Microsoft offers 3 values. "Allow user consent for apps" lets any user grant any permission that does not require admin consent, which covers all 5 here. "Allow user consent for apps from verified publishers, for selected permissions" lets users grant only the permissions you have classified as low impact, which by default is none of these. "Do not allow user consent" sends everything to you. On either of the last 2, a user connecting a Microsoft 365 mailbox to this service is blocked at Microsoft's screen and never reaches us.

Approving once, with the link above, is enough: the grant is recorded against the app in your tenant and every later user connects without a prompt, whatever the user consent setting says. You do not need to change that setting, reclassify any permission, or approve each person.

If you would rather your users asked than forwarded notes, Microsoft's admin consent workflow does that. Turned on under Enterprise apps, Consent and permissions, Admin consent settings, it gives the blocked user a box to send a request from Microsoft's own screen, emails your designated reviewers, and lets a reviewer with the right role approve it from the admin centre. The approval a reviewer makes there is the same tenant-wide grant as the link above, so it also needs making only once.

Revoke it

For the whole organisation. Open Enterprise apps, All applications, find Mailbox MCP, and either delete it from its Properties pane (at least a Cloud Application Administrator; it sits in the recycle bin for 30 days) or, if you may want it back, set Enabled for users to sign in to No, which stops token issuance and keeps the configuration. Either way, no new sign-in succeeds from that moment, and every existing connection from your tenant fails at its next token refresh. Microsoft's access tokens last roughly an hour, so that is about the longest any connection outlives the revocation. The control panel then marks each affected mailbox as needing reconnecting and does nothing else with it.

For one person. The user removes the mailbox from their own control panel, which deletes the token we hold for it; their AI clients lose the mailbox that minute. From your side, revoking the user's sessions in Entra invalidates every refresh token issued to that user, ours included, and has the same effect on our connection as it does on every other app they use.

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 approve 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 Google Workspace instead, or on both, the Google Workspace page is the one to read. There is less to approve on that side: Gmail is connected with an app password over IMAP and needs no app allowlisting at all, and only the calendar app has a client ID to mark Trusted.

Frequently asked questions

Does Mailbox MCP ask for application permissions on Microsoft 365?

No. The app, application ID 02774f59-3ae8-483e-9698-7102f0f18c52, registers 5 delegated permissions (IMAP.AccessAsUser.All, Mail.Send, Calendars.ReadWrite.Shared, MailboxSettings.ReadWrite, offline_access) and no application permissions at all. Every one of them works only while a user is signed in and only as that user, so nothing the app holds can open a mailbox whose owner has not signed in and consented, and it asks for no directory permission of any kind. A tenant-wide grant removes the consent prompt each user would see; it does not give the app any access without a user.

What happens after I grant tenant-wide admin consent to Mailbox MCP?

The app appears under Enterprise applications in your tenant with its 5 delegated permissions granted for all users, and people in your organisation who connect a Microsoft 365 mailbox no longer see a consent prompt. Each of them still signs in as themselves, still chooses which mailbox to connect, and still connects only their own. The approval itself connects nothing: the person who asked you goes back to the control panel and finishes. Microsoft returns your browser to the app's registered redirect URI with admin_consent=True, and nothing about your tenant is stored by that return.

Can I approve Mailbox MCP for one user rather than the whole organisation?

Not as a per-user grant, because Microsoft records admin consent per tenant. If your policy lets users consent for themselves, each user already grants the app for their own mailbox only. If it does not, Microsoft's route is to grant tenant-wide consent and then set Assignment required to Yes on the enterprise application, so only the users and groups you assign can sign in to it. The admin consent workflow, if you turn it on, lets a blocked user send a request from Microsoft's own screen instead of forwarding a note, and a reviewer's approval there is the same tenant-wide grant.

How do I revoke Mailbox MCP's access for my organisation?

In the Microsoft Entra admin centre, under Enterprise apps, find Mailbox MCP and either delete it from its Properties pane, which needs at least a Cloud Application Administrator and keeps it in the recycle bin for 30 days, or set Enabled for users to sign in to No, which stops token issuance and keeps the configuration. From that moment no new sign-in succeeds and every existing connection from your tenant fails at its next token refresh, which Microsoft's access token lifetime puts at roughly an hour. A single user can end their own connection sooner by removing the mailbox in their control panel, which deletes the token held for it.

Sources

Every statement above about Microsoft Entra was read off one of these pages on 13 September 2026. The app's own identifiers were read out of the production service configuration the same day.

• Microsoft Learn: Grant tenant-wide admin consent to an application The form of the consent URL, the roles that can grant it, the Enterprise applications path, and the assignment-required alternative to approving for everyone.
• Microsoft Learn: Admin consent on the Microsoft identity platform The parameters the consent endpoint takes, the admin_consent=True return, and the warning never to trust the tenant ID in that return.
• Microsoft Learn: Configure how users consent to applications The 3 user consent settings, their wording, and the low-impact classification that decides what users may grant on the recommended one.
• Microsoft Learn: Configure the admin consent workflow What the workflow does for a user who cannot consent, where it is switched on, and who can review a request.
• Microsoft Learn: Delete an enterprise application The deletion path, the role it needs, the 30-day recycle bin, and deactivation as the alternative that keeps the configuration.
• Mailbox MCP: Connect a Microsoft 365 mailbox The user's side of the same connection, including the permission table in the words the consent screen uses.

Read 13 September 2026 Every Microsoft Entra fact on this page was read off the Microsoft Learn pages listed under Sources on that day. If it has changed since, tell us and we will read it again.