Status: Public Preview — behaviour may change.

What it does

SharePoint Tools in Work IQ let an agent or app work with SharePoint and OneDrive content through the same capabilities Copilot in SharePoint uses. They cover finding site content, organising files, maintaining lists and libraries, approvals, sharing, version recovery and knowledge-base management. They're exposed as resource paths under /sharepoint in the Work IQ MCP interface, not as a fixed catalogue of named tools.

Key facts

• You need Work IQ enabled in the organisation first.
• Access needs WorkIQ.Read (read only) or WorkIQ.Act (changes content or configuration, and includes read). Discovery filters the paths to the scopes in the token, so a read-only token never sees the write paths.
• A token carrying only WorkIQAgent.Ask sees no /sharepoint paths at all.
• Scopes don't widen what the signed-in user can already reach in SharePoint, and tenant governance policies still apply.
• Microsoft says paths and parameters will change while existing scenarios keep working. You're meant to discover paths and schemas at runtime instead of hard-coding them.
• File-transfer scenarios return download instructions and upload-session details (including resumable sessions). They don't move the bytes for you.
• The new scopes come with a separate v2 Work IQ CLI application so existing deployments don't break. Setup and consent guidance for it was still pending in the source article.

When to use / skip

Use it when an agent needs to do real SharePoint work: tidy a library, maintain list data, chase an approval, restore a deleted file. Skip it if you only need to read content for grounding; the retrieve tool or standard connectors are lighter, and you don't want to hand an agent WorkIQ.Act for a read-only job.

Configuration decisions

• Read or Act. Default to WorkIQ.Read and add Act only for agents with a named, tested write scenario.
• Whether to consent the new scopes on your existing Work IQ CLI app or register a new application.
• Which tenant governance policies apply to Work IQ MCP, and who owns them.

Gotchas

• An agent that works in a demo with an Ask-only token will find no SharePoint tools in another environment. It's the scope, not the agent.
• Write scenarios include deleting lists and libraries and batch list changes. Test them against a sandbox site first; the recycle bin is a safety net, not a plan.
• Hard-coded tool names and parameters will rot. Build the discovery step in from day one.
• It's preview, so don't promise a client a production approval flow built on it.

Consultant notes

• The first design question is which identity the agent acts as. With delegated tokens it inherits the user's SharePoint permissions, which is exactly what you want and exactly what exposes years of broken site permissions. Check oversharing before the pilot, not after.
• Approvals and e-signature tracking are tempting demo material. Agree who is accountable when an agent approves or cancels something, because "the agent did it" won't satisfy an auditor.
• Keep Act-scoped agents on a small set of sites at first and log what they change. UAT should include a deliberately bad prompt.

---

Revisit when the tools reach general availability or the v2 CLI application guidance is published.