Your agent needs to read and write SharePoint: pull the SOW from a project site, update a list item when a deal closes, drop a generated report into a document library. Microsoft now ships both a first-party MCP server and the Microsoft Graph API surface that has backed SharePoint integrations for years. They are not two views of the same thing. One is a preview feature gated behind a Copilot license with a 5 MB file ceiling; the other is a versioned REST surface with webhooks, delta queries, and resumable uploads. Here's how to pick.
These are two Microsoft-built surfaces over the same underlying data, released roughly a decade apart, with very different design intents. The MCP server is built for LLM clients inside a governed tenant. The API is built for applications. Establishing what each one actually is up front removes most of the confusion in the comparison that follows.
Microsoft's first-party SharePoint MCP server ships under Agent 365 as part of the Work IQ tool family. The server ID is mcp_SharePointRemoteServer and the tenant-scoped endpoint is https://agent365.svc.cloud.microsoft/agents/tenants/{tenantId}/servers/mcp_SharePointRemoteServer. It is built directly on Graph and exposes 35 tools spanning site discovery, document libraries, files and folders, lists, columns, list items, sharing invitations, and sensitivity labels.
It is a preview feature. Microsoft states plainly that it might change preview tool names and parameters, and advises against hard-coded dependencies. Access requires a Microsoft 365 Copilot license, and clients reach it through Copilot Studio, Microsoft Foundry, or a coding agent configured against an Entra app registration holding the matching Work IQ SharePoint permission.
Official docs: Work IQ SharePoint reference on Microsoft Learn and the Work IQ MCP overview.
Graph models SharePoint as site, list, listItem, drive, and driveItem resources under https://graph.microsoft.com/v1.0/sites/.... Every capability the MCP server exposes is reachable here, plus change notification subscriptions, delta cursors for incremental sync, file version history, check-in and check-out, content types, recycle bin restore, Microsoft Search with KQL, and resumable upload sessions.
Auth is standard Microsoft Entra OAuth 2.0. Delegated flows let the agent act as a specific user with that user's site and library permissions intact. Client credentials give you app-only access for background work with no user in the loop. One honest limitation worth naming: Graph v1.0 provides read-only support for site resources, so creating new site collections still needs the beta endpoint or a different API.
Official docs: SharePoint API in Microsoft Graph and the SharePoint sites and content overview.
Four dimensions decide this: what the agent can call, what auth model each path forces, what you still own once it is running, and which scenarios each one actually fits. Capability first, because for SharePoint the gap is unusually concrete.
Work IQ SharePoint covers the interactive document and list surface well. It handles the tasks that make up most of what a knowledge worker asks an agent to do inside SharePoint: find a site, browse a library, read a file, update a list item, share a document. The gaps show up the moment an agent needs to watch for changes, move real files, or page through more than a screenful of results.
The 5 MB ceiling. Microsoft caps Work IQ SharePoint file operations at 5 MB for both upload and download. That is not a soft guideline; it is stated in the server description and repeated on every file tool. A contract PDF with embedded scans, a quarterly deck, a CAD export, or most video assets are simply out of reach. Graph handles 250 MB in a single PUT and anything larger through createUploadSession, uploading in sequential byte ranges under 60 MiB each.
No event surface. Nothing in the 35-tool list subscribes to change notifications or returns a delta cursor. If your agent needs to react when a document lands in a library or a list item flips status, the MCP path cannot express that. Graph gives you both mechanisms: subscriptions for push, delta for a resumable incremental sweep that catches whatever push dropped.
The top-20 wall. getFolderChildren returns the top 20 items. findSite returns the top 20 sites. Search returns the top 20 by default. The Learn reference documents no pagination parameters on these tools. An agent auditing a 4,000-document library cannot get there from here. Graph exposes $top, $skip, $filter, $orderby, and cursor paging on the same resources.
Work IQ SharePoint runs on Microsoft Entra OAuth against a registered client application. An administrator or an authorized user registers an app in Entra, adds the Work IQ SharePoint permission, consents to it, and configures a redirect URI. Each MCP server corresponds to a permission on the Agent 365 application, and admins can allow or block servers tenant-wide from the Microsoft 365 admin center.
There is no API key path and no static credential path. Every connecting user completes a browser-based consent flow, and access is subject to workspace governance by default. For enterprise deployments that governance is a feature. For an agent that needs to spin up without an admin in the loop, it is a dependency you plan around.
The Graph API supports the same delegated Authorization Code flow plus Client Credentials for app-only access. Delegated tokens are the right model when the agent must act as a specific person and inherit their SharePoint permissions. App-only tokens are the right model for tenant-wide background work. Both are available; the MCP path gives you exactly one of them. To understand the broader tradeoffs between OAuth vs API Keys for AI agents, it's worth reviewing why static credentials break down in production systems.
Microsoft is explicit: you must have a Microsoft 365 Copilot license to use Work IQ MCP servers. That is a per-seat commercial dependency sitting underneath a technical integration decision, and it does not apply to Graph at all. If you are shipping a B2B product where each customer connects their own tenant, you are now asserting that every customer has bought Copilot.
The headless gap compounds it. A nightly document classifier, a scheduled compliance sweep, an event-driven pipeline that files incoming attachments into the right library: none of these have a browser or a user present at execution time. Graph's client credentials flow was built for exactly this. The MCP path was not. Understanding how tool calling auth changes when you move from single-tenant to multi-tenant is essential context here.
On the MCP path, Microsoft owns hosting, scaling, tool schemas, and permission enforcement. Observability is genuinely strong here: admins can query trace logs of agent tool calls in the Microsoft Defender portal through Advanced Hunting, including which tools ran, what parameters were passed, and what came back. If your buyer is a CISO who already lives in Defender, that is a real advantage.
What you still own on the MCP path: per-user token storage, refresh, revocation on disconnect, tenant isolation, and the Entra app registration lifecycle. On the direct API path you own all of that plus endpoint selection, request construction, retry logic, pagination, subscription renewal, and adapter code per resource type. More surface area, more control.
Both paths consume the same budget. SharePoint Online throttling is enforced per client application per tenant on a resource-unit model scaled by tenant license count, and MCP tool calls resolve to Graph calls underneath. Throttled requests return 429 or 503 with a Retry-After header, and SharePoint returns IETF RateLimit headers ahead of the limit in some conditions. Agentic workflows fire several sequential calls per user action, so budget accordingly and honor the headers.
Schema stability differs sharply. Graph is versioned: you pin v1.0, and breaking changes go through deprecation. Work IQ SharePoint is a preview whose tool names and parameters Microsoft warns may change, with the explicit instruction to avoid hard-coded dependencies. For a deterministic pipeline where an unannounced schema change is an incident, that distinction is the whole decision. This is one reason why understanding the difference between MCP and APIs matters before you commit to a path.
Use Work IQ SharePoint MCP when:
Use the Microsoft Graph SharePoint API when:
Both paths hand you a credential per user and nothing else. The MCP OAuth flow produces a token per user. The Graph delegated flow produces a token per user. In neither case does the path give you a vault, rotation logic, tenant isolation, or a revocation flow. That infrastructure gets built separately regardless of which path you chose.
Take a document intelligence agent serving 60 knowledge workers across 9 customer tenants. That is 60 access tokens to store encrypted, 60 refresh tokens to rotate before expiry, and 60 credentials to invalidate when someone leaves. Add subscription renewal on top if you are using webhooks, because Graph change notification subscriptions on SharePoint resources max out at roughly three days and must be renewed before expiry or the event stream goes quiet.
The failure mode is specific and silent. An employee's Entra account is disabled during offboarding, but a refresh token minted eight months ago is still sitting in your database. The agent does not decide to keep using it. It just does, until something returns 401 and nobody is watching for it. This is the exact scenario that secure token management for AI agents at scale is designed to prevent.
Scalekit's SharePoint connector resolves the per-user credential on every tool call, so every SharePoint action is attributed to the person who authorized it rather than a shared service account. Tokens live in a vault outside the agent runtime, encrypted at rest and namespaced per tenant, and never appear in prompts, logs, or LLM context. The same infrastructure works whether you build against MCP or Graph directly, which is the point: the path decision does not change what you need at the credential layer.
Scalekit ships one SharePoint connector, and it is the Graph-backed API path with 39 prebuilt tools. There is no separate SharePoint MCP connector in the catalog, which reflects the licensing and headless constraints described above. What you get instead is the ability to expose any scoped subset of those Graph-backed tools over an MCP endpoint through Virtual MCP servers, covered further down.
SharePoint is a bring-your-own-credentials connector. Create the connection in the Scalekit dashboard under AgentKit, Connections, Create Connection, then copy the redirect URI it generates. Register a multitenant application in Microsoft Entra, paste that redirect URI as a Web redirect, generate a client secret, and enter the client ID, secret, and Graph scopes back in the Scalekit connection.
Note the connection name you choose. Every connection_name in your code must match the connection name configured in the dashboard exactly. This is the single most common integration error, and it surfaces as a confusing not-found rather than an obvious misconfiguration.
The agent never sees a SharePoint token. It works with an identifier, which is any stable string that identifies the user in your system, and Scalekit resolves the credential server-side at call time.
Before the agent runs, load its tool surface. This is not a connector catalog dump. list_scoped_tools returns the tools the current user's connected account is authorized to call, filtered further by the tool names you allow for this agent role.
The SharePoint connector exposes 39 tools. A contract review agent needs five. Handing the model all 39 costs roughly 200 tokens each, so about 7,800 tokens burned before the agent does any work, and it degrades selection accuracy because the model is choosing from a decision space it was never designed to handle at that scale. Scoping to five cuts the overhead by roughly 87% and shrinks the decision space to what is actually relevant.
Permissions come from the same place. sharepoint_search runs against Microsoft Search as the authorizing user, so sites Priya cannot open in a browser are equally unreachable by the agent acting for her. What the user can't do, the agent can't do. Surface reduction is the lever here. Model upgrades help; they are not the lever.
Scalekit's LangChain adapter returns native StructuredTool objects, so there is no schema reshaping. Pass the same filters you used above. For a deeper look at how LangChain tool calling works and where it stops, that guide covers the full picture.
Prebuilt tools cover the common surface. When you need something outside it, such as a delta cursor or a version history call, actions.request proxies raw Graph requests with the user's token injected server-side. Your application still never handles the credential.
The same discovery, scope, and execution sequence in Node. listScopedTools returns JSON Schema you pass straight to the Anthropic API.
If you want an MCP endpoint without the Copilot license, the Entra registration per tenant, and the 5 MB ceiling, Virtual MCP servers give you one. You declare which connections and which tools an agent role can see, and Scalekit generates a static endpoint. There is no MCP server to deploy, host, or maintain.
A document agent rarely touches only SharePoint. It reads the library, checks the Jira ticket, and posts to Slack. One server definition covers all three, and it is created once for the role rather than once per user.
Note what is absent from that list. No sharepoint_delete_list, no sharepoint_recycle_item, no sharepoint_delete_role_assignment. A review agent that can permanently delete a list is an incident waiting for a bad tool selection. The agent sees only what you explicitly allow, not everything the connector exposes.
The endpoint is static. The identity is not. Before each run, confirm the user's connections are still live, then mint a short-lived token bound to that specific user's connected accounts.
SharePoint is where cross-tenant leakage does real damage, because a document library is not a row in a table; it is contracts, board decks, and HR records. One server definition serving all users with a per-run session token means no credential sharing between users and no per-user server configuration to drift out of sync. Cross-tenant tool calling requires per-tenant authorization, and there is no shortcut.
The check before minting matters as much as the mint itself. OAuth credentials expire or get revoked between runs, and confirming status up front turns a mid-task failure into a re-auth prompt the user can act on. This is why understanding how to handle token refresh for AI agents is a production concern, not an afterthought.
The MCP path gives you Defender-based tracing inside the tenant, which is useful to the customer's security team and invisible to you as the vendor. When your agent misbehaves for one customer, you cannot open their Defender portal.
Scalekit logs the downstream side. Every execute_tool call returns an execution_id, and each entry ties the SharePoint action back to the connected account that authorized it: which user, which connection, which tool, what came back. History is retained for 90 days and exports in a SIEM-friendly shape.
That matters because standard application logs record a user ID and a timestamp, while an agent action touches four principals at once: the user who triggered it, the agent process that ran it, the identity whose OAuth token was spent, and the tenant it executed in. When a compliance reviewer asks whether the agent was authorized to open a specific site, the answer has to reference the authorization event, not just the request. Persisting execution_id alongside your own trace ID gives you that link in one hop. For a comprehensive look at this topic, agent tool observability covers what it takes to know your agent is actually working correctly.
If your users sit in a Copilot-licensed tenant, your agent runs interactively, and the work is finding and lightly editing small documents and list items, Work IQ SharePoint is a legitimate path with governance and Defender tracing included. Account for the preview status and the instruction to avoid hard-coded tool dependencies.
If your agent runs headless, touches files above 5 MB, needs webhooks or delta sync, has to page through libraries larger than 20 items, or serves customers who have not all bought Copilot, build against Microsoft Graph. Those are architectural boundaries in the current MCP server, not configuration options.
Most production SharePoint agents will end up on Graph for the pipeline and reach for MCP-shaped ergonomics through a scoped Virtual MCP endpoint. Either way the credential management problem is identical, and that is the part that needs production-grade infrastructure.
Browse the Scalekit SharePoint connector docs for the full 39-tool reference and setup steps, or the SharePoint connector page for framework snippets and starter prompts.
Building something and want a second pair of eyes on the auth model? Join the Scalekit Slack community to compare notes with other agent builders, or talk to an engineer if you need help right now.
