MCP claude.ai Microsoft 365 connector rejects personal Microsoft accounts (Hotmail/Outlook.com/Live)
Summary
The bundled claude.ai Microsoft 365 MCP connector cannot authenticate personal Microsoft accounts (@hotmail.com, @outlook.com, @live.com). The OAuth flow halts at the Microsoft sign-in page with the error:
You can't sign in here with a personal account. Use your work or school account instead.
Reproduction
- In Claude Code, run
/mcp. - Select claude.ai Microsoft 365 → start auth flow.
- Browser opens
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=08.... - Enter a personal MSA email (e.g.
name@hotmail.com). - Microsoft displays the rejection above before any consent screen is shown.
Expected
Personal Microsoft accounts (Outlook.com / Hotmail / Live) should be accepted, since the connector targets Outlook mail and OneDrive — both of which are first-class personal-account services. Many users' primary mailbox is @hotmail.com.
Likely root cause
Anthropic's OAuth app registration appears to use signInAudience = AzureADMyOrg or AzureADMultipleOrgs (work/school only) instead of AzureADandPersonalMicrosoftAccount. The /common endpoint accepts personal MSA only when the app's audience permits it.
Requested fix
Re-register (or update) the OAuth app with signInAudience = AzureADandPersonalMicrosoftAccount so both work/school and personal accounts can authenticate.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/supported-accounts-validation
Workarounds users currently need
- Forward Hotmail → a working provider (e.g. Gmail) and ingest via
claude.ai GmailMCP. - Build a custom IMAP poller against
imap-mail.outlook.com:993using a Microsoft account app password.
Both are awkward and shouldn't be necessary for what is a primary consumer mail/storage product.
Environment
- Claude Code (CLI), Opus 4.7
- macOS 25.4.0 (Darwin)
- Browser: Chrome
- Affected MCP:
claude.ai Microsoft 365(claudeai-proxy athttps://microsoft365.mcp.claude.com/mcp) - Affected account type: personal MSA
Showing cached comments. Read the full discussion on GitHub ↗
6 Comments
Claude MCP for Azure DevOps is broken due to the same cause: it can't log in to the DevOps server with a personal account
This is still an issue, highly reduces functionality of some solutions being offered.
This is still an issue.
I'd love to use Claude with my Outlook personal accounts - it's great to have Gmail as an option, but there are thousands of users who started with Hotmail/Outlook and are diehards and not willing to switch to another email provider. Based on the commentary above, this seems like a fairly easy and quick fix to update the OAuth files.
Ran into this today trying to connect my personal Microsoft 365 subscription (paid, consumer plan) via Cowork. The OAuth flow rejects personal accounts with "you can't sign in here with a personal account" — same root cause as described here.
This feels like a significant gap given how many individuals use Microsoft 365 Personal/Family rather than a work tenant. Changing signInAudience to AzureADandPersonalMicrosoftAccount in the app registration would cover both cases. Happy to test if a fix is rolled out.
Retested this today (2026-07-15) right after the latest Claude Desktop update. Update notes list several MS365-connector auth fixes (Company Portal sign-in, corporate TLS-inspection networks, admin-consent prompt on restrictive tenant policies), but none of those touch this issue — same rejection as before: "You can't sign in here with a personal account. Use your work or school account instead."
For whoever picks this up: the OAuth request scopes
api://07c030f6-5743-41b7-ba00-0a6e85f37c17/.default(via client08ad6f98-a4f8-4635-bb8d-f1a3044760f0) — so it's specifically the resource app07c030f6-...(not just the client) whosesignInAudienceneeds to change toAzureADandPersonalMicrosoftAccount. Worth checking that resource app's registration directly if the client-app setting already looks correct.