SharePoint MCP Server: Setup, Tools & Real Limits
A SharePoint MCP connection can make sites, lists, and files callable by an AI agent, but the right server depends on which SharePoint product you actually mean.
A SharePoint MCP server lets an AI client call SharePoint operations as tools: find a site, inspect lists, read rows, or change content. Today, though, there is no single universal Microsoft package for every SharePoint workload. Choose between Microsoft’s hosted Agent 365 services, its SharePoint Embedded developer server, or a community Graph wrapper.
Table of contents
- What SharePoint MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What SharePoint MCP actually is
A SharePoint MCP server is an adapter between an MCP client and SharePoint’s APIs; it is not a new SharePoint database or an all-knowing company search engine. The client sees named tools with schemas, chooses one, and sends arguments, while the server handles Microsoft authentication and Graph requests.
In concrete terms, an agent can resolve a site, enumerate document libraries and lists, retrieve list-item fields, create or update rows, and sometimes search files. What it can do is determined by the installed server’s tool catalog and the signed-in identity. MCP itself does not bypass SharePoint permissions: the MCP tools specification explicitly treats tool metadata as untrusted and expects clients to keep a human in control of sensitive calls.
That makes MCP best for exploratory, multi-step work, not fixed nightly exports. Compare the proposed scope with our MCP capabilities guide.
What exists today
There are credible options today, but they serve different SharePoint products and have different production stories. My view: prefer Microsoft’s hosted service when your Agent 365 environment supports it; use the community server for local experimentation; use the Embedded server only for Embedded application work.
| Option | Intended use | Maturity and trade-off |
|---|---|---|
| Microsoft Agent 365 OneDrive/SharePoint and SharePoint Lists remote servers | Files, sites, libraries, and lists in Microsoft 365 agents | Microsoft-hosted and governed, but tied to Agent 365 setup and availability |
@microsoft/spe-mcp | Provisioning and operating SharePoint Embedded apps and containers | First-party, open source, and currently preview; not a general intranet connector |
@softeria/ms-365-mcp-server | Ordinary Microsoft 365 data through Graph, including SharePoint in organization mode | Broad and convenient, but community-maintained and therefore your team owns review, pinning, and incident response |
Microsoft’s official MCP catalog lists hosted OneDrive/SharePoint and SharePoint Lists endpoints. Microsoft also documents @microsoft/spe-mcp as a local preview developer tool for SharePoint Embedded, not SharePoint Online generally. Its source repository is inspectable, which is valuable, but “first-party” does not turn preview software into a production SLA.
The community Microsoft 365 MCP server maps hundreds of tools to Graph endpoints. That breadth consumes context and expands the action surface. Check our official-server collection if vendor ownership is required, or compare the wider best MCP servers shortlist.
Setup
For a normal SharePoint Online proof of concept, the shortest verifiable route is the Softeria server in organization, read-only mode. For production, I would first test Agent 365’s managed remote server, which avoids running a community package beside every client.
Prerequisites and authentication
Start with a work or school Microsoft 365 account, Node.js 20 or newer, an MCP-compatible client, and tenant approval for the Graph scopes you need. The community server uses device-code authentication by default and can report its calculated permissions with --list-permissions; SharePoint tools require --org-mode. Its README also supports OAuth authorization code flow for HTTP deployments and a bring-your-own-token mode.
Do not paste a long-lived bearer token into client JSON. Use interactive OAuth locally, then move production authentication into managed identity controls. Microsoft Graph’s selected permissions model is the key boundary: Sites.Selected can restrict an application to granted sites, whereas tenant-wide scopes reach much further.
Client configuration
This Claude Desktop-shaped configuration is copied from the project’s documented package and flags; other clients use the same command but may name the top-level field differently. Starting read-only is the opinionated choice.
{
"mcpServers": {
"ms365": {
"command": "npx",
"args": ["-y", "@softeria/ms-365-mcp-server", "--org-mode", "--read-only"]
}
}
}
- Add the entry to the configuration location documented by your client. Our config generator can help with the outer client format.
- Restart the client, call the server’s
logintool, and complete the Microsoft device-code flow. - Verify the signed-in account before retrieving anything.
- Test against a non-sensitive site and request one known list.
- Inspect logs and returned fields before considering write access.
For SharePoint Embedded, do not reuse that block. Microsoft’s setup guide specifies Node.js 22+, Azure CLI sign-in, tenant-admin access, and npx -y @microsoft/spe-mcp start; it also documents the exact delegated container permissions for a pre-provisioned Entra app.
Tools you get
Tool names are server-specific, so never prompt against a generic blog’s list. The following names come directly from the community server’s versioned endpoint catalog and cover the ordinary SharePoint list workflow.
| Tool name | What it does |
|---|---|
search-sharepoint-sites | Finds sites the authorized scope can discover |
get-sharepoint-site-by-path | Resolves a known hostname and site path to a site object |
list-sharepoint-site-drives | Lists a site’s document libraries |
list-sharepoint-site-lists | Lists the site’s SharePoint lists |
list-sharepoint-site-list-items | Retrieves list items; expand fields to obtain column values |
list-sharepoint-list-columns | Reads list schema before row operations |
create-sharepoint-list-item | Adds a row to a list |
update-sharepoint-list-item | Changes selected fields on an existing row |
delete-sharepoint-list-item | Deletes a row, subject to SharePoint recovery behavior |
Expose only the tools needed for the workflow. A model offered hundreds of unrelated Microsoft 365 schemas spends context understanding choices and has more ways to select the wrong action.
Permissions and blast radius
Start read-only, restrict the app to named sites, and use a dedicated integration identity where the server supports your authentication model. A dedicated account makes audit records legible and prevents an employee’s changing role or departure from silently changing the agent’s reach.
The SharePoint blast radius is concrete. A bad update can overwrite business fields; a deleted column removes its data across items; a sharing change can expose a library; and an upload can trigger workflows. Microsoft Graph supports read-write operations on lists and drive items but only read access for some site resources, as its SharePoint Graph overview explains.
Keep writes behind explicit confirmation, log tool name and arguments, and require the agent to read the current object immediately before mutation. I would avoid tenant-wide write scopes for conversational use. Sites.Selected plus per-site grants takes more administration, but the trade-off is worth it: a prompt mistake becomes a site-level incident rather than a tenant-wide one.
Real limits
The main limits are pagination, context size, throttling, API coverage, and imperfect model judgment. MCP changes the interface to Graph; it does not remove Graph’s service behavior or make every SharePoint UI feature programmable.
A large list may return a page plus a continuation link, not the whole dataset. Even if a server follows pagination, sending thousands of rows to the model wastes tokens and can bury the relevant records. Filter and select fields server-side, fetch IDs first, and summarize in batches. Microsoft’s Graph guidance recommends $select and $expand to return only necessary data, while its paging documentation requires clients to follow @odata.nextLink correctly.
Throttling is workload-dependent rather than one reassuring universal requests-per-minute number. SharePoint assigns different resource-unit costs to operations; permission calls cost more than a single-item read, and throttled responses include Retry-After. Microsoft’s SharePoint throttling guidance recommends honoring those headers and reducing request frequency. An agent that retries immediately can turn a temporary 429 into a longer failure.
Graph also cannot create SharePoint sites through the general site resource API, and MCP cannot reliably reproduce every page-design, web-part, taxonomy, or admin-center action unless its chosen server exposes a supported endpoint. Browser automation is not an equivalent substitute; it is brittle and harder to govern.
When not to use it
Do not use a SharePoint MCP server when the job is deterministic, high-volume, or already served by Microsoft’s own agent experience. MCP earns its complexity when a model must choose among several operations based on messy human intent.
Use a plain Graph script or Power Automate flow for scheduled synchronization, migrations, bulk edits, or any process needing repeatable transactions and precise retry handling. Use SharePoint agents or Microsoft 365 Copilot when users mainly need permission-trimmed answers from documents inside Microsoft’s governed interface; Microsoft says SharePoint agents respect each user’s existing access in its admin guidance.
I would also avoid MCP for redesigning modern SharePoint pages. The common Graph surface focuses on sites, lists, and drives, not faithful visual authoring. The honest decision rule is simple: choose MCP for supervised, variable workflows; choose an API script for repeatability; choose Microsoft’s native AI when retrieval and governance matter more than custom tool orchestration.