All documentation
On this page
For administrators
For Microsoft 365 admins
Somebody in your tenant has tried to connect their own mailbox to an AI assistant through this service, and Microsoft has told them your organisation needs an administrator to approve the app first. This page is written for that administrator: what the app is, what it asks for and why, what it can never do, how to approve it once for everyone, and how 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.
For a Microsoft 365 mailbox the connection is one Microsoft sign-in. The user is sent to Microsoft and signs in as themselves. 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. 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.
| Display name | Mailbox MCP |
| Application (client) ID | 02774f59-3ae8-483e-9698-7102f0f18c52 |
| Publisher | BSolve IT Limited, company 04607330, England and Wales |
| Publisher verification | Verified by Microsoft on 30 August 2026. The consent prompt carries the blue verified badge. |
| Sign-in audience | Multitenant: accounts in any organisational directory |
| Redirect URI | https://app. |
| Permission type | Delegated only. No application permissions are registered. |
The consent prompt names the publisher, not the product
Microsoft shows the verified publisher on its prompt, and the verified publisher has to be the company as it appears on the public register. So your user's screen reads BSolve IT Limited where they expected Mailbox MCP. Same app, same ID.
The 6 delegated permissions
All 6 are delegated. Each acts only as the user who signed in and consented, with that user's rights. None of them can open a mailbox whose owner has not signed in.
A routine the user sets up in their own Claude or ChatGPT, which can run on a schedule while they are away, uses these same delegated permissions, as that user.
| Permission | API | What it is used for |
|---|---|---|
IMAP. |
Exchange Online | Opening the mailbox over IMAP as the signed-in user: listing, searching and reading messages, moving and flagging them, saving drafts. Requested against https://outlook.office.com/, which is where Exchange accepts it. |
Mail. |
Microsoft Graph | Sending, replying and forwarding as the signed-in user, through Graph rather than SMTP, so Authenticated SMTP stays off. Not Mail.Send.Shared: it never sends on behalf of anyone else. |
Calendars. |
Microsoft Graph | The calendar: reading and writing events in the user's own calendars and in calendars already shared with them, and to ask Microsoft for free meeting times across attendees (findMeetingTimes), which needs the shared form of the permission. It widens nothing; Microsoft still decides what that account may see. A personal Microsoft account (Outlook.com, Hotmail, Live) cannot hold this permission, so it is also asked for Calendars.ReadWrite, its own calendar only, without the free/busy of other people; that permission is never asked of a work or school account. |
MailboxSettings. |
Microsoft Graph | The user's time zone and working hours, without which a time cannot be stated correctly, and the out-of-office reply, which Exchange keeps as a mailbox setting. |
Contacts. |
Microsoft Graph | The user's own Outlook contacts: looking a person up, opening a card, adding, correcting and deleting one, and importing a contacts file, in the default Contacts folder, the user's own top-level contact folders and their child folders one level deep. ReadWrite because cards are written as well as read. It reaches nothing shared or delegated (those folders are not the user's own), and never a contact's photo. |
offline_access |
Microsoft identity platform | A refresh token, so the connection outlives the browser session and the user is not sent back to sign in every hour. |
None of the 6 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. 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. 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.
And one thing the contacts permission does not reach, since it is
Contacts.ReadWrite and not the .Shared form:
a contacts folder another user has shared or delegated to the
signed-in user is never read or written, only the user's own default
Contacts folder, their own top-level contact folders and those
folders' children one level deep.
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, mailbox settings and contacts.
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 6 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.
Tenant-wide admin consent link
https://login.microsoftonline.com/organizations/adminconsent?client_id=02774f59-3ae8-483e-9698-7102f0f18c52&redirect_uri=https%3A%2F%2Fapp.mailbox-mcp.com%2Fmailboxes%2Fmicrosoft-callback%2F&state=admin-consent
Needs a role that can grant tenant-wide consent. Opens on 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 6 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 6 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 you would rather not approve it for everyone
Consent is granted per tenant, so there is no per-user grant for an administrator to make. What Microsoft offers instead 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. Microsoft's page on tenant-wide consent, under Sources, describes both steps.
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.
| The setting's value | What it lets users grant |
|---|---|
| "Allow user consent for apps" | Any permission that does not require admin consent, which covers all 6 here. |
| "Allow user consent for apps from verified publishers, for selected permissions" | Only the permissions you have classified as low impact, which by default is none of these. |
| "Do not allow user consent" | Nothing. Everything is sent 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. It is 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, and find Mailbox MCP. Then do one of 2 things:
- Delete it from its Properties pane. That needs at least a Cloud Application Administrator, and 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. It 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. 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 one app for the calendar and Google contacts 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 6 delegated permissions (IMAP.AccessAsUser.All, Mail.Send, Calendars.ReadWrite.Shared, MailboxSettings.ReadWrite, Contacts.ReadWrite, offline_access) and no application permissions at all. Each acts only as the user who signed in and consented, so nothing the app holds can open a mailbox whose owner has not, and it asks for no directory permission of any kind. A tenant-wide grant removes the consent prompt each user would see; it gives the app no access of its own.
What happens after I grant tenant-wide admin consent to Mailbox MCP?
The app appears under Enterprise applications with its 6 delegated permissions granted for all users, and people who connect a Microsoft 365 mailbox no longer see a consent prompt. Each still signs in as themselves, chooses which mailbox, and 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 redirect URI with admin_consent=True, and nothing about your tenant is stored.
Can I approve Mailbox MCP for one user rather than the whole organisation?
Not as a per-user grant: Microsoft records admin consent per tenant. If your policy lets users consent, each already grants the app for their own mailbox only. If not, Microsoft's route is tenant-wide consent with Assignment required set to Yes on the enterprise application, so only the users and groups you assign can sign in. The admin consent workflow lets a blocked user request it from Microsoft's own screen; 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. Delete it from its Properties pane (at least a Cloud Application Administrator; 30 days in the recycle bin), or set Enabled for users to sign in to No, which keeps the configuration. No new sign-in then succeeds, and every existing connection fails at its next token refresh, within roughly an hour. A user can end their own connection sooner by removing the mailbox in their control panel.
Sources
Every statement above about Microsoft Entra was read off one of these pages on . 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.