Work IQ is a Copilot plugin marketplace for Microsoft 365 data

A marketplace, not a service API

The project describes itself as the official Microsoft Work IQ plugin collection for GitHub Copilot, and the top line of the repository is a plugin marketplace rather than a library.

The contents are MCP servers, skills and tools that connect AI assistants to Microsoft 365 data. That is the product: a set of packages, each one exposing a way of reaching tenant data to an agent, plus the CLI and the MCP server that make the connection.

The four plugins in the catalogue are where the substance is. The `workiq` plugin queries Microsoft 365 data with natural language, covering emails, meetings, documents, Teams messages and more. The `workiq-preview` plugin is a preview build with a different policy, described as agent-host-neutral, retrieve-first context with explicit Grounding when available, intentional delegation via `ask`, and exact entity reads, writes and downloads, and the documentation is careful to say that this preview policy does not change the public `workiq` routing policy. The `microsoft-365-agents-toolkit` plugin is a toolkit for building and evaluating M365 Copilot declarative agents, covering scaffolding, manifest authoring, capability configuration and eval workflows. And `workiq-productivity` is read only, giving email triage, meeting costs, org charts and channel audits.

The data types it can reach are listed plainly. Emails, for example what John said about the proposal. Meetings, what is on the calendar tomorrow. Documents, find my recent PowerPoint presentations. Teams, summarize today's messages in the Engineering channel. And People, who is working on Project Alpha.

The audience is a developer inside a Microsoft 365 tenant who wants an assistant that can read their work data, and the platform support list covers `win_x64`, `win_arm64`, `linux_x64`, `linux_arm64`, `osx_x64` and `osx_arm64`.

Tenant consent is the gate

The most important paragraph in the README is the one about permissions, and it is the first thing a reader should look at.

To access Microsoft 365 tenant data, the WorkIQ CLI and the MCP Server need to be consented to permissions that require administrative rights on the tenant. On first access a consent dialog appears. If you are not an administrator, the instruction is to contact your tenant administrator to grant access.

For tenant administrators there is a separate document, the Tenant Administrator Enablement Guide in `ADMIN-INSTRUCTIONS.md`, with detailed instructions for granting admin consent, including what the README calls a quick one-click consent URL. Microsoft's own documentation on user and admin consent is linked as well, for the general picture.

This is the design decision that shapes everything else about the project. An agent with access to your mail, your calendar and your Teams messages is a serious privilege, and the designers chose to make that privilege an explicit, tenant-level, administrator-granted thing rather than a per-user OAuth dance inside the tool. The cost is that the tool is not usable by an individual without help, and the benefit is that an organisation can see exactly what was consented to and by whom.

There is a second layer of consent to notice, and it comes from the plugin split. The `workiq-productivity` plugin is explicitly read only, which is a narrower grant than the general query plugin. The preview plugin adds writes and downloads. So even within one tool, what the agent can do depends on which package is installed, and the documentation is explicit about that rather than leaving it to be discovered.

Four ways to run it, from Copilot CLI to npx

The installation options are laid out from most integrated to most standalone, and the shortest path is inside GitHub Copilot CLI.

You open the Copilot CLI, add the marketplace once, and install whichever plugin you want.

# 1. Open GitHub Copilot CLI
copilot

# 2. Add this plugin marketplace (one-time setup)
/plugin marketplace add microsoft/work-iq

# 3. Install any plugin
/plugin install workiq@work-iq
/plugin install workiq-preview@work-iq
/plugin install microsoft-365-agents-toolkit@work-iq
/plugin install workiq-productivity@work-iq

Then you restart Copilot CLI and ask questions in the ordinary way, such as what are my upcoming meetings this week, summarize emails from Sarah about the budget, or find documents I worked on yesterday.

The standalone path installs the package globally and runs the MCP server yourself.

# Install globally
npm install -g @microsoft/workiq

# Run the MCP server
workiq mcp

The same thing without installing anything uses npx, and the documentation notes that npx automatically fetches the latest version each time, so there is no manual update step in that case.

npx -y @microsoft/workiq mcp

And for an IDE or agent that speaks MCP, the server is configured as a command with arguments.

{
  "workiq": {
    "command": "npx",
    "args": ["-y", "@microsoft/workiq@latest", "mcp"],
    "tools": ["*"]
  ]
}

The `tools` array of `"*"` is worth a look, because it is the difference between granting the agent the whole tool surface and granting it a subset.

The prerequisite for all of it is Node.js 18 or newer, with npm and npx included, and the README explains why that matters: WorkIQ uses npx to run the MCP server, and npx comes with npm, which comes with Node.js. You can check with `node --version` and `npm --version`.

The CLI itself is three commands

The command line reference is short, and the shape of it tells you that the CLI is a thin companion to the server rather than a product of its own.

There are three commands. `workiq ask` asks a question to a specific agent or runs in interactive mode. `workiq mcp` starts the MCP stdio server for agent communication. And `workiq version` shows version information.

The global options are equally few. The `-t, --tenant-id` option selects the Entra tenant ID to use for authentication and defaults to `common`, which is the multi-tenant default rather than a fixed tenant. `--version` prints the version, and `-?, -h, --help` shows the help and usage information. The `ask` command has a single option of its own, `-q, --question`.

So the interactive path, the scripted path and the version check are the whole surface.

# Interactive mode
workiq ask

# Ask a specific question
workiq ask -q "What meetings do I have tomorrow?"

# Use a specific tenant
workiq ask -t "your-tenant-id" -q "Show my emails"

# Start MCP server
workiq mcp

The tenant option is the one that matters in a multi-tenant organisation, where a common default would otherwise send a request to whichever tenant the account happens to be signed in to. Setting `-t` explicitly is the difference between a query you can reason about and one you cannot.

For a globally installed copy, the update path is npm's own.

npm update -g @microsoft/workiq

and `workiq version` verifies what you ended up with, which matters here because there is no GitHub release history to check against.

Adding a plugin means adding four files

The contribution guide is a four step list, and the marketplace is a file you can read.

You create your plugin under `plugins/{your-plugin}/`, you add `.mcp.json`, `README.md` and `skills/{name}/SKILL.md`, you register it in `.github/plugin/marketplace.json`, and you submit a pull request.

That tells you the shape of a plugin exactly. The `.mcp.json` file is the MCP server definition, the `SKILL.md` file is the skill description that tells the agent what the tool is for and how to call it, the README is the human documentation, and the registration in `marketplace.json` is what makes it installable by name with `/plugin install your-plugin@work-iq`.

The repository root has a `marketplace.json` and a `server.json` as well, alongside `PLUGINS.md` for the full catalogue with detailed skill listings, example prompts, MCP server info and installation instructions, plus `scripts/`, `tests/`, a `.claude-plugin/` directory and an `AGENTS.md`.

The `skills/` convention is the interesting one. It means a plugin is not only a server, it is a documented set of capabilities, and the skill file is the part an agent actually reads to decide what to call. That is why the plugin descriptions in the README are so specific about behaviour, for example that `workiq-preview` is retrieve-first with explicit Grounding when available, and that `workiq-productivity` is read only.

A note on the licence and the trademark position. The repository says that by using the package you accept the licence agreement, with the `LICENSE` and `NOTICES.TXT` files holding the legal terms, and that the project may contain trademarks or logos for projects, products or services, with authorised use of Microsoft trademarks or logos subject to Microsoft's Trademark and Brand Guidelines. The repository's licence is not one GitHub classifies as standard, so the files in the root are the text to read.

Public preview and the upgrade path

The banner at the top of the README is short and should be read first. This is a public preview, and features and APIs may change.

That is a significant qualifier for a tool whose whole purpose is to reach into a tenant's mail and calendar. The MCP server interface, the tool names, the plugin boundaries and the consent scopes are all things that can move under you, and the repository has no GitHub releases to pin against. The only version reference is `workiq version` on the installed copy, and the npm package is updated with `npm update -g @microsoft/workiq`.

The npx path makes this concrete in a way that is easy to miss. Running `npx -y @microsoft/workiq mcp` fetches the latest version every time, which the documentation presents as a convenience, and which is also the behaviour that a reproducibility-minded team would want to change. An IDE configuration that hardcodes a version, `npx -y @microsoft/workiq@latest` versus a pinned one, is the difference between a reproducible development environment and one that changes under you when the vendor publishes.

The same applies to the plugin split. The stable `workiq` plugin and the `workiq-preview` plugin do not merely differ in version, they differ in policy, with the preview adding writes and downloads and using a different routing and grounding model. A team that installs the preview into a workflow because it is more capable should do so knowing it is the preview build, and that the documentation states the preview policy does not change the public routing policy, which is a distinction that will matter when a tool behaves differently than expected in one mode and not the other.

Where this is the wrong tool

The boundaries here are mostly about entitlement and about what an agent with tenant-wide access should be allowed to do.

The first is the admin gate. If you do not have administrator rights on the tenant and cannot get them, this tool is simply unavailable to you, and no amount of configuration on your own machine changes that. A developer evaluating it needs to establish that a tenant administrator will approve the consent before they plan anything else, and the `ADMIN-INSTRUCTIONS.md` document exists precisely so that the conversation with the administrator can be concrete.

The second is the scope of the grant. The general plugin can read mail, meetings, documents and messages, and the preview can also write and download. That is a large surface for an agent to hold, and the fact that a read only variant exists is a signal about how the designers think about it. An organisation that wants an assistant that can summarise but not modify should install the read only plugin and not the preview.

The third is the preview status, which is a real constraint rather than a formality. The APIs may change, there is no release history to pin against, and the npx path pulls the latest version by default.

The alternative approach, and the difference in approach is real, is to write your own MCP server against the same Microsoft 365 APIs your tenant already exposes to your application, with your own scopes and your own consent request. You get control over exactly what the agent can reach, you can pin versions, and you keep the audit trail of who asked for what. What you give up is the packaged query logic, the natural language routing, the agents toolkit and the productivity insights, and the work of maintaining a server that has to keep up with the API.

The honest framing is that Work IQ is a convenience for a tenant that has already decided to let an assistant read its data. Where that decision has not been made, the right first step is not a plugin marketplace.

Editorial conclusion

Work IQ suits a developer who wants an agent to query a Microsoft 365 tenant they are already entitled to, and who can get a tenant administrator to approve the consent once. It is the wrong tool for a shared machine without tenant admin access, and the wrong tool for anything that has to be reliable today, since the project is in public preview and its features and APIs may change. Check first whether your organisation has an admin who can run the consent flow described in ADMIN-INSTRUCTIONS.md, and read the plugin policy difference between the stable `workiq` plugin and the `workiq-preview` build before you wire either into a workflow.

Frequently asked questions

Official sources

1. Issues
2. microsoft/work-iq on GitHub
3. README