Microsoft 365 MCP Servers: What They Are (2026 Guide)
Nov 12, 202614 min read
View Microsoft 365 MCP as permissions, not features
What Microsoft 365 MCP servers actually are
"Microsoft 365 MCP" isn't a single product you switch on. It's a family of servers, some run by Microsoft and some by third parties such as Activepieces, that let an AI client reach mailboxes, files, calendars and chats.
Which one you pick decides what the agent can touch.
Someone on your team has probably already wired a community server to their own Microsoft account with a personal token. That's the real starting point.
The sanctioned alternative is to decide, deliberately, which server runs, under whose identity, and with what scopes. Least privilege for an agent is a design problem, and it gets solved when you choose the server. Vendor details below reflect the November 2026 check.
What MCP is in one paragraph
The Model Context Protocol is an open standard that lets an AI client call tools and read data exposed by a server, without a custom integration for each pairing.
The client asks what the server offers, the model picks a tool, and the server executes it against a real system.
The protocol is neutral on trust, so the permissions model is where the risk sits.
Three things get called "Microsoft 365 MCP", and they differ mainly in who operates them:
- Microsoft-hosted MCP servers, run by Microsoft, so your tenant admin governs access through the identity and consent controls you already use.
- Copilot Studio MCP connectors, which let agents built in Copilot Studio call MCP servers. Microsoft runs the platform, while your makers decide what each agent connects to.
- Self-hosted community servers over Microsoft Graph, run by whoever deploys them, with code maintained by volunteers and permissions set by whoever registered the app.
This takes minutes, not a project: automate it in Activepieces free.
Permissions enforcement in Microsoft 365 MCP
When an AI client asks an MCP server to act, the server calls Microsoft Graph, and Entra decides what it may touch.
The client is the app the person talks to, such as a desktop assistant or an agent builder. The MCP server translates the client's tool calls into requests.
Microsoft Graph is the API behind mail, calendar, files and Teams. The server holds no data of its own, so its reach is whatever token it presents to Graph.
In Entra, that token gets its limits. Delegated permissions let the agent act as the signed-in user, so it sees only what that person sees.
Application permissions let it act as itself, usually across the whole tenant. For an agent, least privilege is a design choice made here, and delegated access is the tighter default.
Copilot Studio, desktop clients and community servers
The three routes differ mainly in who maintains the code and where consent happens.
| Route | Maintainer | Microsoft 365 data reached | Authentication | Consent location |
|---|---|---|---|---|
| Microsoft-hosted servers | Microsoft | Graph data the server is built for | Delegated | Entra, by the user or an admin |
| Copilot Studio connectors | Microsoft and connector publishers | Whatever the connector exposes | Delegated or application, per connection | Connection setup, backed by Entra |
| Self-hosted community servers | Community authors | Whatever Graph scopes you grant | Either, set by your app registration | Your own Entra app registration |
The third row is the one growing Only a fragment came through ("fastest, and the one where you own the review."), with no numbers, product names, or documented fact to keep. Please paste the full sentence and I'll return the rewrite.
200 public MCP server repositories on GitHub in Q4 2024 became 3,400 in Q1 2025, according to AgentRank. They reached 9,800 in Q2, 15,200 in Q3 and 21,100 in Q4 2025.
In Q1 2026 there were 25,750. That's more than a hundredfold rise in five quarters, so your staff will find a Graph-capable server faster than your security team can vet one.
What Microsoft 365 MCP costs and requires
For Microsoft 365 MCP only the licence layer is confirmed. It runs $7 to $39 per user per month, and every other line is still unconfirmed.
The table below separates confirmed figures from unconfirmed ones, so budget the confirmed rows as fixed and the rest as open questions.
| Item | Published price or setting | Source page | Status | Check date |
|---|---|---|---|---|
| M365 licence | $7 to $39 per user per month | workaicompare.com | Confirmed | 2026-11-12 |
| Copilot licence | $21 to $30 per user per month | workaicompare.com | Confirmed | 2026-11-12 |
| Copilot Studio capacity | No figure found | None | Unconfirmed | n/a |
| Admin consent | No setting confirmed | None | Unconfirmed | n/a |
| Tenant settings | No setting confirmed | None | Unconfirmed | n/a |
| Azure hosting | No figure found | None | Unconfirmed | n/a |
Microsoft 365 MCP licences and tenant prerequisites
Doubling the tier doubles the bill for every seat: ITBroker.com and workaicompare.com list Business Basic at $7 per user per month and Business Standard at $14.
Business Premium is $22 and Microsoft 365 E3 is $39, which means a full-tenant rollout on E3 costs more than five times the entry tier.
Licensing every seat for an agent that a few teams use is the expensive way to start. Copilot Business is $21 and Copilot Enterprise is $30, and Copilot Business alone costs three times Business Basic.
Don't look for a confirmed figure on admin consent or tenant settings, because there isn't one here. Treat them as design work: decide which agent gets which scopes before anyone clicks approve.
Usage charges follow agent traffic, so a pilot's cost says little about a production bill. This article has no Copilot Studio capacity price. Get the figure from Microsoft's current pricing page before committing a budget.
If you run the server yourself, Azure hosting gets added, and no hosting figure is confirmed here. That cost depends on where the server runs and how much traffic it handles.
The tradeoff is control over permissions against an infrastructure bill and an owner for patching.
Built-in security for Microsoft 365 MCP
If you run a Microsoft tenant, you can argue that the tradeoff above mostly doesn't apply to Microsoft-hosted servers. Those servers sit behind the identity, access and compliance controls the tenant already enforces, and they act only as the signed-in user.
Five controls carry this argument, and each answers a different question about what an agent can do. Together they show that the case rests on reuse, not on new agent-specific safeguards.
- Entra sign-in, Microsoft's identity service, establishes who is calling, so every request traces to a named account.
- Conditional Access checks device, location and risk conditions before it allows a session, and can block an agent client the same way it blocks a risky laptop.
- Purview, Microsoft's compliance tooling, applies sensitivity labels and data-loss rules that travel with the content the agent touches.
- Acting only as the signed-in user means the agent sees what that person can see, and nothing their existing permissions don't already grant.
- Central admin governance lets administrators decide which servers and clients are approved, from the console they already use.
None of this is a new policy to write. It's policy already written, extended to a new client.
Why admins can approve Microsoft 365 MCP
Start with what people are doing already. Staff paste mailbox content and documents into whatever assistant is open in a browser tab, outside every one of these controls.
Against that baseline, a sanctioned server that signs in through Entra, is gated by Conditional Access and leaves an audit trail is a real improvement. An admin who says yes is choosing the more governable of two paths.
The design argument holds up too. Least privilege for an agent is hard because agents tend to hold their own credentials, and those credentials accumulate scope.
Delegated access sidesteps that: the agent's ceiling is the user's ceiling, and when the user leaves, the access goes with them. There's no separate service account to rotate and no second identity to review.
The weak point is the phrase "as the signed-in user", because a user's ceiling is often far higher than any single task needs.
You can follow the rest of this with the builder open. Start free, no card.
Over-permissioning risks in Microsoft 365 MCP
That gap is where the mistakes start. A prompt-injected agent inherits everything the signed-in user can do, so every excess permission is reachable by whoever writes the injected text. Five mistakes recur:
**A prompt-injected agent inherits everything the signed-in user can do, so every excess permission is reachable by whoever writes the injected text.
- Broad Graph scopes such as Files.ReadWrite.All: let one hijacked request read or overwrite every file the user can reach.
- Unvetted community servers put code you haven't reviewed between the agent and your tenant.
- Stored tokens turn one leaked file into standing access that outlives the session.
- No logging means you can't say afterward what the agent touched.
- Open-ended agents on fixed processes hand judgment to a model where a script would do.
It works for every demo, which is why Files.ReadWrite.All is easy to grant. It also means an agent summarizing one SharePoint folder can edit all of them. Scope to the task, and ask what the smallest grant is that still lets the job finish.
An SDK hands an agent code to run, but it supplies no tenant, no role and no audit log, and that is how agents end up running blind inside a Microsoft 365 tenant.
For fixed, repeatable work, such as a trigger feeding a set approval, Activepieces offers a Microsoft 365 connector, a separate route from Microsoft's own MCP servers, and agents get least-privilege access of their own, with custom RBAC and control over which apps a team may connect deciding what they can reach, so each agent is limited to the apps and permissions it has been granted, and a team can only connect the apps an admin allows.
Each tool call is logged separately with its own input and output, which answers "what did the agent touch" call by call. MoneyGram and Moneypenny run it in production.
Unvetted community servers and stored tokens
To gauge how much a server can do on your behalf, count its tools. Third-party servers expose far more tools than Microsoft's own. The community ms-graph-mcp lists 53 tools, so you have 53 actions to review before approving it.
MCP-Microsoft-Office lists 117, which makes a real review a project rather than an afternoon. A 365 admin server lists 674, and at that size nobody on your team will read every tool, so you're trusting the author rather than checking.
Stored tokens compound this. A refresh token sitting in a config file lets a compromised server act as the user long after they close the app. Prefer short-lived tokens, and keep them out of files the agent can read.
When Microsoft 365 MCP is the wrong fit
If the process is "when an invoice arrives, file it and notify finance," a workflow with fixed steps needs only the permissions for those steps.
An open-ended agent needs the whole menu, because you can't predict which tool it will pick. Reserve agents for work where the path is unknown.
Together these point to one design question: what is the least this agent must be able to do?
What to do with Microsoft 365 MCP
Answer that design question in order. Start with what is already connected: inventory the MCP servers, narrow what each can touch, route consent through an admin, log everything, then pilot one read-only use.
Microsoft 365 MCP rollout checklist for admins
Someone on your team has probably already pointed an AI client at their mailbox or a shared drive, using whatever server they found first. Banning that tends to push it further out of sight.
The sequence below brings it into view and then replaces it with something you chose. Each step is cheap on its own, and each makes the next one safer.
- List every connected MCP server in use, separating Microsoft's own from third-party ones, and note who connected it and with which account. You can't narrow what you haven't found, so the list is the prerequisite for everything below.
- Narrow the Microsoft Graph scopes. For each server, compare the permissions it requests with what its task needs. A summarizer of meeting notes needs read access to those notes, not read-write access to every mailbox. Trading a little convenience here removes most of the damage a misbehaving agent could do.
- In Microsoft Entra, require admin consent: stop users from approving app permissions on their own, so new servers and scope expansions go through a person who reads the request. This adds a small delay, and the delay is the control.
- Make sure agent activity lands in Microsoft Purview audit, tied to an identity you can name. When something odd happens, the log is the difference between an answer and a guess.
- Pick one read-only task where a wrong answer costs minutes, such as searching documents or summarizing a thread, and run it with the narrowed scopes. Write access can be argued for later, with the pilot's logs as evidence rather than enthusiasm.
Finishing these gives you a defensible baseline, and the pilot's logs show which permissions the agent actually used and which it only held.
Frequently asked questions
Four questions about the servers themselves sit outside what any pilot can show. The pilot's logs tell you what the agent did, and each question has a short answer from Microsoft's own documentation:
- Whether you need a Copilot licence depends on the server, and each server's documentation states its own requirement.
- Whether a server can write data depends on the tools it exposes and the permissions you consent to.
- Community servers can be used, because MCP is an open protocol, but Microsoft doesn't vouch for them.
- Logs sit in your tenant's existing audit and sign-in records, not in a separate MCP console.
Is Microsoft 365 MCP free to use? The protocol is open and carries no fee of its own. Cost comes from what sits behind the server: the licences, capacity and consumption of the Microsoft service it reaches, plus whatever a third-party vendor charges.
Budget for the permissions you grant, not for MCP itself.
Does Microsoft 365 MCP work with ChatGPT or Claude? It can, where the client supports remote MCP servers and the server's authentication allows it. Your tenant admin still has to consent to the connection. Treat each client as its own approval, not a blanket yes.
Do I need Copilot licences to use it? Not as a rule for the protocol. Some Microsoft servers are tied to Copilot or agent products, and others aren't, so check the requirements on the specific server before you plan seat counts.
Can MCP servers change or delete my data? Only if the server exposes write tools and the identity behind it holds write permissions. A read-only scope makes deletion impossible for that agent.
That's the design lever: grant the narrowest scope the task needs, and widen it only when the logs show a real reason.
Related reading
Build it
Set this up in minutes.
No code required. Connect your accounts, and Activepieces runs it from there.
Start free Talk to sales
