[FEATURE] Allow individual plans to enable Microsoft 365 write tools
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The Microsoft 365 connector's write tools (sending mail, creating drafts, calendar and SharePoint writes, shipped 7 July 2026) can only be enabled via Organization settings > Connectors — a surface that individual Pro/Max plans do not have. There is no per-user path to opt in.
I can demonstrate the effect cleanly, because I hold both plan types under one account:
| Workspace | Read tools | Write tools |
|---|---|---|
| Team plan | 10 | 28, incl. Outlook send mail |
| Personal Max plan | 10 | 0 — section absent |
Same user, same Microsoft work account, same Entra tenant, same connector endpoint (microsoft365.mcp.claude.com/mcp). The only variable is the workspace type.
The Microsoft side is fully provisioned in both cases. Under My Apps > "M365 MCP Server for Claude" > permissions approved by your administrator, my account has Mail.Send, Mail.ReadWrite, Calendars.ReadWrite and MailboxSettings.ReadWrite granted. Disconnecting and reconnecting the connector, a fresh consent round and "Refresh tool list" change nothing — the personal workspace stays at exactly 10 read-only tools.
Anthropic support confirmed this is intentional: "write tools are currently limited to Team and Enterprise workspaces where admins can control their enablement."
The reasoning behind the gate is sound in general — an employee should not enable risky tools without oversight. But it does not fit single-user tenants, which is a large share of the people affected here. I am the Global Administrator of my own Entra tenant. I approved these exact Graph scopes myself. Admin and user are the same person, and the oversight step has already happened in Entra. The gate blocks me from something I have already authorised.
Proposed Solution
Give individual plans a way to opt into write tools, with whatever confirmation friction you consider appropriate. Concretely: a per-tool toggle under Customize > Connectors > Microsoft 365 > Tool permissions, behind an explicit warning that the user is enabling tools which can send mail and modify data on their behalf.
Everything needed to enforce safety already exists and would carry over unchanged. Write tools in my Team workspace default to "approval required" per call. "Always allow" is already blocked for send operations regardless of plan. The connector still cannot exceed the user's own Microsoft 365 permissions. And Entra admin consent remains a prerequisite, so a tenant admin can still withhold the scopes entirely.
So this is not a request to weaken the safety model. It is a request for a second place to flip a switch that already exists, for users who have no first place.
If a full toggle is considered too permissive, a narrower version would still help: enable write tools only when the signed-in Microsoft account is a Global Administrator of its own tenant, or require re-confirmation per session.
Alternative Solutions
Tried and ruled out. Disconnecting and reconnecting the connector with full re-authentication, a fresh Entra admin consent round, "Refresh tool list", new chats and new Cowork sessions — none of it changes anything, the tool list stays at 10 read-only tools.
Moving my work into the Team workspace technically works, but my project, skills, plugins and scheduled tasks all live in the personal workspace, and the Team workspace is shared with colleagues. Putting a private mailbox and personal projects there to work around a toggle is not a reasonable trade.
Building a custom MCP server with my own Entra app registration is viable, but it means hosting and maintaining a server to regain a capability the official connector already implements and that my tenant has already authorised.
Current workaround: sending via n8n against POST /me/sendMail. It works and is trigger-capable, but it means Claude cannot send in the flow where the message is actually being written — which is the entire point of the connector's write tools.
Priority
High - Significant impact on productivity
Feature Category
MCP server integration
Use Case Example
A typical scenario from my week. I ask Claude to prepare a short message to my management team, based on a Notion page and last week's meeting notes — all of which Claude can already read through the connector. Claude drafts it, and the content and tone are right. Then it stops: Claude cannot create the draft in my mailbox, let alone send it. I copy the text out of Claude, open Outlook, paste, fix the formatting, add the recipients, send.
That last step is the whole gap. Everything before it works today. The connector can read the source material but cannot put the result where it belongs — in a mailbox it already has full read access to, in a tenant where Mail.Send is already granted.
The same pattern applies to creating a calendar entry after a meeting, and to filing a generated document into SharePoint.
Additional Context
Documentation gap, worth fixing regardless of whether this feature request is accepted: the setup article explicitly marks the connector enablement step as "Team and Enterprise plans only", but the write tools section carries no equivalent note. For members it only documents how to turn tools off, never that they cannot turn them on. Read on an individual plan, it implies that updated Entra admin consent is sufficient. That cost me a full round of disconnect/reconnect, consent verification in Entra, tool-list refreshes and a support ticket before I found the actual cause. One sentence in that section would save other individual-plan users the same detour.
Related: issue 20469 was closed once connector availability was extended to all plans. This is the follow-on for write tools, which shipped afterwards. Several commenters there describe exactly the profile affected here — solo consultants and small business owners who administer their own Microsoft 365 tenant.
Also related: learn.microsoft.com/answers/questions/5945851 (13 July 2026), another Max-plan user with all write scopes consented in Entra, same read-only result, same failed reconnect. Still unanswered.
Happy to provide screenshots of both tool lists and of the granted Graph permissions if that helps.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Also impacted, plz fix
Also impacted, fix needed
Same here
Would love this to be enabled for individual plans.
Adding a second configuration to this, since it's a different permutation than the one in the original report and it defeats the stated safety rationale from the other direction.
Setup
So this isn't the solo-admin case. There is a separate Global Administrator, and he did exactly the oversight step the gate is supposed to enforce.
What was done
Working alongside our Entra Global Administrator, screen-sharing, on 29 July 2026:
M365 MCP Client for Claude(08ad6f98-a4f8-4635-bb8d-f1a3044760f0) andM365 MCP Server for Claude(07c030f6-5743-41b7-ba00-0a6e85f37c17).Files.ReadWrite.All,Mail.ReadWrite,Mail.Send,Calendars.ReadWrite,MailboxSettings.ReadWrite, all delegated and admin consented.get_methat the session was authenticated as my licensed account and not the tenant admin account (it had silently connected as the admin on a prior attempt).Result: 10 read-only tools. No write section. Same as the original report.
Why this permutation matters
The rationale quoted in the original report is that write tools are limited to Team and Enterprise "where admins can control their enablement." The original reporter's answer is that he is the admin, so the oversight already happened.
My case is the inverse and I think it's the stronger one. There is a real, separate administrator. He reviewed the scopes. He consented deliberately and tenant-wide. That is precisely the oversight the gate exists to require, performed by precisely the person it exists to involve, and the tools still do not appear. The gate isn't enforcing admin oversight here, it's ignoring it and substituting a billing check.
Documentation cost, corroborating the point in the original report
I want to underline this because it's cheap to fix and expensive to hit. Following the "Write tools aren't appearing for members" section of the setup article, an individual-plan user reads it as a configuration problem, because that section only documents how to turn tools off. There is nothing indicating that individual plans have no path to turn them on.
That cost us a multi-hour session with our Global Administrator, two service principal recreations, a full consent round, and a support ticket, to arrive at a state that was unreachable by design before we started. One sentence in that section would have saved all of it. That's real IT time at a real company, spent on a dead end the docs implied was live.
Commercial context
We're currently evaluating Claude against the alternative for firm-wide rollout. We are a Microsoft 365 shop. Read-only access to SharePoint and Outlook is genuinely useful and the connector works well within that limit. Write access is the difference between a research tool and a workflow tool, and the fact that an individual plan cannot reach it even with full tenant consent is a live factor in that decision.
Happy to provide screenshots of the Entra consent state and both tool lists.