Work IQ MCP: Eleven Tools That Give an Agent All of Microsoft 365

In Copilot Studio you connect tools to an agent. Work IQ MCP is one of them. It sits under Microsoft IQ and gives the agent access to the organization's own information: email, calendar, Teams, files, meetings, and business systems, within the user's permissions.

Most MCP servers grow in step with what they cover. A server for email gets one tool per operation, one for calendar does the same, and before you know it the agent has sixty tool definitions in context to choose between.

Work IQ does the opposite. All of Microsoft 365 is exposed through eleven tools, and that number is designed not to grow no matter how many workloads are added. It is a design choice worth understanding even if you never intend to touch Microsoft's platform, because the problem it solves exists in every MCP integration.

This article goes through how it works, what the eleven tools do, and why almost everything is read only until someone actively changes it. The material is Microsoft's documentation plus two measurements of our own: one straight against Work IQ's MCP endpoint, and one in a Copilot agent with Work IQ connected. If you would rather understand the runtime all of this runs in first, there is inside the GitHub Copilot harness.

What Work IQ Is

Microsoft IQ is the umbrella name for four layers: Work IQ for how employees work, Fabric IQ for the live state of the business, Foundry IQ for curated institutional knowledge, and Web IQ for the outside world.

Work IQ is the workplace layer. It lets agents access, understand, and act on organizational data in Microsoft 365 and external systems, with permission-aware governance built in. You reach it through three standard protocols: A2A for agent to agent, MCP for tool-based access, and REST for ordinary request-response calls.

Two things are worth knowing right away, because they often come as a surprise.

“Microsoft 365 Work IQ is read only unless an administrator explicitly turns on write operations in the Microsoft 365 admin center.”

Source: Work IQ in Microsoft Copilot Studio

One detail that is easy to miss in licensing discussions: Work IQ does not require a Microsoft 365 Copilot license. It is offered with usage-based billing, and cost and governance are handled centrally in the Microsoft 365 admin center.

The Design Principle Is the Interesting Part

Three principles carry the whole construction, and they are stated clearly enough to borrow.

“Fewer tools, more paths. Generic tools operate on resource paths. New workloads add paths, not tools - the tool surface never grows.”

Source: Work IQ MCP overview

The policy over scopes principle deserves a footnote. Microsoft writes that four broad OAuth permissions govern the capability, but the permission reference currently lists exactly one: WorkIQAgent.Ask, delegated, with admin consent, described as “read and write access to Microsoft 365 resources that are accessible to Work IQ agents”. The block on writing therefore does not sit in the permission, it sits in the tenant policy.

In practice that means fetch /me/messages reads email, do_action /me/sendMail sends a message, and create_entity /me/events creates a calendar entry. The same handful of verbs, different paths. Microsoft's own phrasing is that WorkIQ entity paths borrow from the conventions of Microsoft Graph, so anyone who knows Graph will feel at home immediately.

The Eleven Tools

When Work IQ was connected as an MCP server in a Copilot agent, the agent's capabilities went from 123 to 146, and the number of built-in tools from twelve to 23. The eleven additions are these, in our own summary. The tools' own wording, verbatim, comes in the next section.

The last two are highlighted because they are the most important ones to understand. The whole introspection principle rests on them, and they are also the only ones that are hard to guess your way to.

The Tools in Their Own Words

An MCP tool consists of two parts: a schema that describes the parameters, and a description in plain text. The description is not documentation for you. It is the prompt the model reads when it decides whether the tool fits, and it is the only place where Microsoft can put rules the agent follows in the moment.

That is why they are worth reading. Here is the description of fetch, verbatim from tools/list:

“Fetch one or more WorkIQ entities by path. Use entity paths discovered from ask responses or well-known paths like /me/messages. Returns JSON array with results for each path. WorkIQ entity paths borrow from the conventions of Microsoft Graph. Always include a $select query parameter with only the fields you need to reduce response size (e.g., /me/messages?$select=id,subject,from). For collection endpoints, include $top to limit results (e.g., /me/messages?$select=id,subject&$top=10). Some APIs do not support $top (e.g., /me/chats/{id}/members) — omit $top for those. Use the get-schema tool to discover available fields if unsure. For file content (documents, images, photos — e.g. /content or $value endpoints), use fetch_blob instead.”

Roughly half the text is instruction rather than description. The same pattern repeats: search_paths points onward to fetch_blob, do_action and create_entity tell the agent to run get_schema first, and update_entity warns that some paths replace the entire entity. The tool description is where Work IQ steers the agent's behavior, and it is written for a model that reads fast.

Sometimes it turns contradictory. In do_action, jsonBody is marked as required in the schema, while the description of that same field opens in capitals with “OPTIONAL — some actions require a body”. In search_paths and get_schema there are fields the schema calls optional and the description calls “Required.” An agent that trusts the schema and an agent that trusts the text will do different things.

The server name and version come from its own response to initialize, as does the protocol version. One detail worth knowing for anyone building against the endpoint: Microsoft writes that MCP clients discover authentication through /.well-known/oauth-protected-resource, but that path answers 400 BadRequest with the message “Invalid request, no valid route.”

One Observation: There Are Eleven, Not Ten

Microsoft's overview page describes Work IQ MCP as ten generic tools, and the category table adds up to ten: six entity, two copilot, and two schema.

The tool reference opens the same way, verbatim: “The Work IQ MCP server exposes 10 tools.” Then the same page documents eleven of them, with a full parameter table for each. So fetch_blob is in the reference, but missing from the count and from the category table.

A connection to the endpoint gives eleven. The principle of few tools holds up, then, but the number does not. Use eleven if you are showing the observed tool list, and ten if you are quoting Microsoft's categorization. Do not mix them.

How They Are Used in Practice

A few patterns recur throughout the tool reference, and they are the kind of thing that decides whether an integration works or turns into guesswork.

Always start with get_schema. Before create_entity, update_entity, or do_action, you need to know which fields are required. If you do not even know which path exists, you start one step earlier, with search_paths and a regular expression such as .*calendar.*.

All paths are relative. No base URL, ever.

Always limit what you fetch. The tool reference is explicit that $select should be used with only the fields you actually need, for example /me/messages?$select=id,subject,from. For collections, $top limits the number of results. Some endpoints do not support $top, for example /me/chats/{id}/members.

Etags are not optional when updating. If the schema declares If-Match, it must be set to the @odata.etag from your latest read of the same entity. Some paths also replace the entire entity, which means every required field has to be sent along, not only the ones you are changing.

“If the operation's schema declares an If-Match header parameter, you MUST set it to the @odata.etag value from the latest read of the same entity.”

Source: the input schema for update_entity and delete_entity. The headers parameter does not appear in Microsoft's tool reference.

Files do not go through fetch. For file content, fetch_blob is used. The 4 MB limit applies to the raw file and is a default that can be configured per path. A file that exceeds it returns a tool error containing the applicable limit, not any content.

One more pattern runs through all of it: ten of the eleven tools take an optional agentId to target a specific agent ID, and the exception is list_agents, which takes no parameters at all. For ask, the default value is bizchat-as-gpt-scenario. Here the sources disagree: Microsoft's tool reference calls agentId “Reserved for future use” on most of the tools, while the schema the endpoint returns says “Optional agent ID to target a specific agent”.

The Four Components Behind the Tools

The tools are only one of four parts. The other three explain why Work IQ is more than an API wrapper.

Chat is optimized for agent to agent collaboration and web applications, so tasks can be delegated and answers delivered coherently. Context collects and grounds contextual data internally in Microsoft 365, which saves agents from handling raw data or building retrieval pipelines of their own. Tools are the eleven tools. Workspaces uses SharePoint Embedded as persistent working memory inside the tenant boundary, where agents can save intermediate results, reuse them, and hand tasks over to other agents.

Workspaces is the least talked about and perhaps the most interesting. A shared working memory inside the tenant boundary is exactly what multi-step processes across several agents usually lack.

Governance Is the Point, Not an Afterthought

Work IQ gives the agent context from email, calendar, Teams, files, meetings, and business systems. That creates obvious requirements, and Microsoft has built the governance accordingly.

The policy engine uses Rego from Open Policy Agent and evaluates every individual request based on resource path, method, user identity, and content. All actions run within the scope of that specific user's permissions, and every call is logged centrally for auditing, usage analytics, rate limiting, and compliance.

The policy layer is switched on and off per tenant in the Microsoft 365 admin center, under Agents and Tools, and a change can take up to 24 hours to take effect. In the first release there is no governance per user, per app, or per agent.

By default, paths under /me/, /users/, and /sites/ are allowed, while /authentication/ and /servicePrincipals/ are blocked. Mutations are off: create, update, delete, and actions that send email all require an administrator to turn them on.

A detail that is easy to miss: “Policy approval doesn't guarantee the operation succeeds.” A call the policy lets through can still fail on the user's own permissions.

There is a conclusion here that is easy to lose. Governance for the new experience can not be understood through traditional DLP in Power Platform alone. Once Copilot Studio starts using services such as Work IQ, the Microsoft 365 admin center and Agent 365 become central parts of the model, and they sit somewhere other than where the Power Platform administrator is used to looking.

The Older Servers Are Still There

Alongside the generic tools of Work IQ MCP, separate servers per workload still exist. They are more numerous and more specific, which is exactly the development the few tools principle is meant to avoid.

Counting only these six lands you at 104 tool definitions for roughly the same surface Work IQ MCP covers with eleven. That is the concrete difference between adding tools and adding paths.

There is a practical reason to care beyond the elegance: MCP servers count against the total number of tools an agent can host, and the number of servers that can run at the same time in one conversation is capped. Microsoft's own recommendation is short and clear.

“Model Context Protocol (MCP) servers count against the total number of tools an agent can host … keep the count of attached servers small and remove servers you no longer use.”

Source: Tools overview in Copilot Studio

Summary

Work IQ is Microsoft's answer to a question every MCP build faces sooner or later: what do you do when the surface you want to expose is larger than what fits in a tool list.

Four things to take away:

• the answer is verbs plus paths, meaning few tools operating on many paths, instead of one tool per operation
• runtime introspection through get_schema and search_paths replaces loading thousands of type definitions
• everything is read only until an administrator actively turns on writing in the Microsoft 365 admin center
• governance sits partly outside Power Platform, which makes traditional DLP an insufficient mental model

If you want to see the runtime Work IQ plugs into, there is inside the GitHub Copilot harness. If you want to see where MCP fits among the other tool types, and what all of it costs, there is the new Copilot Studio. For the fundamentals of the agent concepts, there is AI agents and agentic systems.

---

About the material. The tool list, the parameters, and the quoted descriptions were captured on 19 August 2026 directly from tools/list against Work IQ's MCP endpoint, meaning the tools' own schemas verbatim. That the same eleven tools with the same parameters are exposed to an agent in Copilot Studio is confirmed by a separate measurement in a Copilot agent with Work IQ connected. The remaining details come from Microsoft's documentation, checked the same day. Work IQ in Copilot Studio is a preview, so expect details to change.