[Bug] brand-voice:microsoft-365 MCP server OAuth fails with AADSTS50011 — redirect URI mismatch on every auth attempt

Summary

The Microsoft 365 connector under the brand-voice plugin (plugin:brand-voice:microsoft-365, served at https://microsoft365.mcp.claude.com/mcp) cannot complete OAuth against Azure AD. Every authentication attempt fails with AADSTS50011 — redirect URI mismatch, because the server generates a random localhost port per attempt but the Azure app registration does not have http://localhost (no-port) registered as a public-client redirect URI.

This is reproducible 100% of the time and is not a tenant-side misconfiguration — the error references the application's registered redirect URIs, which are controlled by the app owner (Anthropic), not the consenting tenant.

Environment

• Client: Claude Code (Windows 11, Opus 4.7 1M)
• MCP server: plugin:brand-voice:microsoft-365 → https://microsoft365.mcp.claude.com/mcp
• Azure AD client_id: 08ad6f98-a4f8-4635-bb8d-f1a3044760f0
• Affected scope: api://07c030f6-5743-41b7-ba00-0a6e85f37c17/.default offline_access openid email
• User tenant: standard M365 commercial tenant (no Conditional Access or app-restriction policies in play; tested by John R. Reeves III on indigenous.health)

Steps to reproduce

1. In a Claude Code session with the brand-voice plugin loaded, invoke mcp__plugin_brand-voice_microsoft-365__authenticate.
2. Open the returned authorization URL in a browser.
3. Sign in with a valid M365 account.
4. Microsoft displays the AADSTS50011 error page before the consent prompt; OAuth never completes.

Observed authorization URLs across two attempts

# Attempt 1
redirect_uri=http%3A%2F%2Flocalhost%3A40303%2Fcallback

# Attempt 2 (fresh auth call, same session)
redirect_uri=http%3A%2F%2Flocalhost%3A49110%2Fcallback

The MCP server picks a new ephemeral port per authenticate call. Azure AD's strict matching rejects all of them.

Error from Microsoft

AADSTS50011: The redirect URI 'http://localhost:49110/callback' specified in the
request does not match the redirect URIs configured for the application
'08ad6f98-a4f8-4635-bb8d-f1a3044760f0'. Make sure the redirect URI sent in the
request matches one added to your application in the Azure portal.

Request Id: 1713099e-e0e8-4f01-b525-21e19cd41200
Correlation Id: 688f0056-38ee-48f3-adc7-07daa2d490d9
Timestamp: 2026-05-23T14:43:34Z

Root cause

Azure AD enforces exact-match on redirect URIs for "Web" redirect types. The only redirect URI configuration that automatically accepts any localhost port is the "Mobile and desktop applications" type with http://localhost registered (no port). Azure documents this loopback-IP exception at <https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url#localhost-exceptions>.

The MCP server's behavior (random port per attempt) is only compatible with that loopback exception, but the app registration for 08ad6f98-a4f8-4635-bb8d-f1a3044760f0 apparently does not have http://localhost registered under "Mobile and desktop applications."

By contrast, the other plugin MCP servers using the same random-port pattern (mcp.notion.com, mcp.clickup.com, mcp.monday.com, api.fireflies.ai) all completed OAuth successfully from the same client session — so the local runtime is doing its job; the Azure-side registration is the problem.

Suggested fix

Update the Azure AD app registration for 08ad6f98-a4f8-4635-bb8d-f1a3044760f0 (or whichever current client_id powers microsoft365.mcp.claude.com) to add http://localhost as a Mobile and desktop applications redirect URI. Once added, the existing random-port flow will succeed without further code changes.

Alternative: fix the MCP server to use a single fixed redirect URI (e.g., https://microsoft365.mcp.claude.com/oauth/callback) and register that URI in Azure. That matches the pattern used by some other connectors but requires server-side relay of the callback.

Impact

brand-voice:microsoft-365 is the only connector path to OneDrive, SharePoint, Outlook, and Teams content for Claude Code users. As long as this is broken, none of those data sources are reachable via the plugin. Users with M365-resident knowledge bases (i.e., most enterprise customers) silently lose the M365 surface.

Workaround

None on the consumer side. Users must:

• Read OneDrive files locally via a synced folder + filesystem MCP, or
• Build a private Microsoft Graph integration in their own Azure tenant.

---

Filed by John R. Reeves III (Indigenous Healthcare Advancements) — reach out via the request/correlation IDs above for full Azure trace.