SharePoint MCP: Documents From an Agent

There are three ways to put SharePoint behind MCP today. Microsoft’s own SharePoint MCP server, in preview, gives agents tools to find sites, read and write files of 5 MB or less, manage lists and columns, share items and set sensitivity labels; Copilot Studio, Microsoft Foundry and coding agents such as Claude Code can use it. Claude’s Microsoft 365 connector, run by Anthropic, searches and reads SharePoint and OneDrive and writes files only when an administrator turns write tools on. And a custom or community server can call Microsoft Graph directly, where Selected permissions can hold it to one site, list or file. As of September 30, 2026, Microsoft’s Copilot Studio docs also label the separate SharePoint tool part of a legacy experience and point new agents at a unified Work IQ server, so check which one your tenant should adopt before you build on either.

Which route fits

• You use Claude and want SharePoint alongside Outlook and Teams: Claude’s Microsoft 365 connector, covered in Claude with Microsoft 365.
• You build agents in Copilot Studio or Microsoft Foundry: Microsoft’s SharePoint server, or the unified Work IQ tool Copilot Studio now recommends.
• You want SharePoint inside Claude Code, GitHub Copilot CLI or VS Code: the same Microsoft server through an app registration of your own.
• You need an unattended agent that touches one site and nothing else: a custom server on Microsoft Graph with a Selected permission.

Microsoft’s SharePoint MCP server

Microsoft’s SharePoint reference↗ (opens in a new tab) marks the server as a preview feature, “not meant for production use”, and warns that Microsoft might change preview tool names and parameters. Its server ID is mcp_SharePointRemoteServer, reached at a tenant-level URL under agent365.svc.cloud.microsoft. The tools fall into groups:

• Sites and libraries: findSite, getSiteByPath, listSubsites, listDocumentLibrariesInSite and getFolderChildren, which returns the top 20 items in a folder.
• Files: findFileOrFolder searches everything the user can reach; readSmallTextFile and readSmallBinaryFile read files under 5 MB; there are tools to create, rename, move, copy and delete files and folders.
• Lists: list, create and delete lists; read, create, update and delete list items; create, update and delete columns.
• Sharing and labels: shareFileOrFolder and sendInviteForList send sharing invitations, and setSensitivityLabelOnFile sets or removes a sensitivity label.

Read the notes before you connect it. Microsoft says list deletion cannot be undone, and deleting a column removes the data in that column for every item. Sharing tools send email to whoever the agent names. Those are the tools to keep behind a person.

Where Microsoft’s pages disagree

• The name. The reference page calls it SharePoint; the Work IQ MCP overview↗ (opens in a new tab) and the Power Platform connector call it Work IQ SharePoint.
• The registry. Microsoft’s entries in the official MCP Registry still list the older mcp_ODSPRemoteServer (OneDrive and SharePoint) and mcp_SharePointListsTools servers, not mcp_SharePointRemoteServer, and Microsoft’s old reference pages for those two IDs now redirect elsewhere.
• The license. The Work IQ overview says a Microsoft 365 Copilot license is required to use Work IQ MCP servers, while Copilot Studio’s newer page says the workload-specific tools use “standard Copilot Studio licensing and billing”. Check with whoever manages your Microsoft licenses before you plan a rollout.

In Claude Code

Coding agents need an app registration in your tenant that acts as the client. The Work IQ overview gives the steps: in the Microsoft Entra admin center, create a registration under App registrations, note its client and tenant IDs, add and consent to the API permission for the server you want (its example uses WorkIQ-MailServer for mail), and add http://localhost:8080/callback as a Mobile and desktop redirect URI. Then put this in a project’s .mcp.json, start Claude Code there, and sign in from /mcp:

{
  "mcpServers": {
    "sharepoint": {
      "type": "http",
      "url": "https://agent365.svc.cloud.microsoft/agents/tenants/{tenantId}/servers/mcp_SharePointRemoteServer",
      "oauth": { "clientId": "{clientId}", "callbackPort": 8080 }
    }
  }
}

Microsoft’s published sample is for the Mail server; this one swaps in the SharePoint server ID from the reference page. The setup, Entra consent and delegated-versus-application choices are the same as in the Outlook MCP server post, so they are not repeated here.

The newer route: Work IQ in one server

Microsoft is moving past one server per workload. Copilot Studio’s page on adding Work IQ↗ (opens in a new tab), updated September 28, 2026, says the separate Mail, Teams, OneDrive, SharePoint and other tools “are part of a legacy experience that remains available for testing and backward compatibility”, and tells builders to pick Work IQ (preview) instead. The same page says Work IQ is read-only unless an administrator turns on write operations in the Microsoft 365 admin center, and that it bills through Copilot Credits.

The unified server works differently. Microsoft’s Work IQ MCP overview↗ (opens in a new tab) describes 10 generic tools, such as fetch, create_entity and delete_entity, that act on Microsoft 365 resource paths through a single endpoint, with access controlled per path and tenant policy rather than by many narrow scopes. For SharePoint work, that means fewer tool names to review and more reliance on the admin policy behind them.

Claude’s Microsoft 365 connector

For Claude users the connector is usually the shortest path, and Claude with Microsoft 365 covers it in full. Two points matter for SharePoint. Anthropic’s guide to setting up the Microsoft 365 connector↗ (opens in a new tab) says it searches SharePoint across the whole tenant with the user’s permissions and cannot be limited to certain sites. And writing files uses the delegated Files.ReadWrite.All permission, which an administrator grants only when write tools are turned on.

Custom servers: hold them to one site

Community SharePoint servers on the MCP Registry, and any server you build yourself, call Microsoft Graph. The permission you consent to decides the damage a mistake can do. Sites.Read.All or Files.ReadWrite.All apply as soon as they are consented. Microsoft Graph’s Selected permissions↗ (opens in a new tab) work the other way: an app consented for Sites.Selected, Lists.SelectedOperations.Selected, ListItems.SelectedOperations.Selected or Files.SelectedOperations.Selected starts with no access until someone grants it a role on a specific site, list, item or file.

POST https://graph.microsoft.com/v1.0/sites/{site-id}/permissions

{
  "roles": ["write"],
  "grantedToIdentities": [
    { "application": { "id": "{client-id}", "displayName": "Proposal agent" } }
  ]
}

• The roles are read, write, owner and full control. Grant read unless the agent must change files.
• Granting a site needs Sites.FullControl.All, so a person with that power does it once; the agent never holds it.
• With delegated tokens, Graph intersects the app’s and the user’s permissions, so the agent never exceeds either. With application tokens there is no user, which Microsoft calls higher risk.
• Revoke in two places: delete the grant on the site, or remove the consent in Entra.

Safe uses, and what a person approves

Documents are written by other people, which makes a shared library a channel for indirect prompt injection. Choose jobs where a planted instruction has nothing worth doing:

• “Find the latest version of the Q3 vendor contract on the Legal site and summarize the renewal terms. Do not change, move or share anything.”
• “List items in the Facilities Requests list that are still open, grouped by building.”
• “Draft a project brief as a new text file in the Drafts folder of the Marketing site. Do not overwrite existing files.”

Deleting files, lists or columns, sharing with anyone, and changing or removing sensitivity labels are for a person to approve, one call at a time, seeing the full request. The broader checklist is in MCP security best practices.

Documents in SharePoint, work on a board

SharePoint holds the spec, the contract and the meeting notes; it is a poor place to track who is doing what next. A useful pattern is to let the assistant read a document and turn what it finds into tasks. With fenbs connected as a second MCP server, it calls fenbs_create_item for each feature, enhancement or bug it finds, with a note that says what and where and links to the document. Tasks land in To Do by default, under the assistant’s own name, and History shows what it filed. fenbs does not connect to SharePoint or store documents, and it has no due dates or settable assignee, so dates and owners stay in the document or with the team.