anthropics / anthropics/claude-code

[FEATURE] Allow individual plans to enable Microsoft 365 write tools

Open
#81,317 8 comments 2 reactions 0 assignees View on GitHub
area:mcp enhancement stale
Dominant language
Python
Stars
145k
Forks
23.1k
PR merge metrics
PR metrics pending

Description

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) 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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the Microsoft 365 connector behavior described in the issue and compare the Team and Personal Max tool lists. Review Customize > Connectors and the setup article's Team and Enterprise wording, then use issue 20469 for prior connector-availability context. Done means individual plans have an explicit write-tool opt-in without bypassing Microsoft permissions or existing approval requirements.

Written by the indexing model from the issue text.

Assessment

Domain
authorization, cloud
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.