>_ The Manifest

Count the tools you currently need to ship one plugin to Microsoft 365 Copilot: a scaffolder, a schema tab, a provisioning CLI, a pile of test prompts, and an admin center tab for telemetry. Five surfaces, five vocabularies, and every handoff between them is a place where what your plugin actually does quietly stops matching what it claims to do.

What Are the Work IQ Developer Tools?

The Work IQ Developer Tools preview collapses that list into a single agentic experience. You stop operating a toolchain and start describing outcomes, and the tooling carries the project state, the conventions, and the platform knowledge that used to live in your head or in a wiki page nobody updated.

⚠️ Warning

WIQD is a developer preview. It is shared for experimentation, not for production, and it is not officially supported yet. Expect breaking changes, and keep it off the critical path of a customer deployment.

Three surfaces install together and share one core, so they never disagree with each other:

  • An agent plugin that teaches your coding agent (GitHub Copilot CLI, VS Code Copilot Chat) the whole plugin lifecycle. This is the daily driver.
  • A VS Code extension with a Language Server that diagnoses manifests and adaptive cards while you type.
  • A wiqd executable that exists mostly so your pipelines have a non-interactive entry point.

One thing worth separating right away, because the naming collides. The Work IQ Platform and APIs are the data plane: the layer that lets agents reason over organizational context with permission-aware governance. The Work IQ Developer Tools are the control plane for your own code. Different products, adjacent problems. This post is about the second one.

# macOS / Linux
curl -fsSL https://aka.ms/wiqd/install.sh | bash

# Windows
iex "& { $(irm 'https://aka.ms/wiqd/install.ps1') }"

That installer also pulls the Microsoft 365 Agents Toolkit along as a dependency. WIQD does not replace it. It orchestrates it, which is the correct relationship: ATK still owns provisioning mechanics and the manifest schema, and WIQD owns the experience wrapped around them. If you want the agent-authoring side of this in detail, creating declarative agents with WIQD covers the scaffolding conventions.

The Plugin Is the Unit, the Agent Is a Composition

WIQD treats the plugin as the durable product unit. A plugin composes the capabilities that carry real value, most often a remote MCP server plus the skills that know how to drive it, and a declarative agent becomes a component of that plugin rather than the container everything reusable has to live inside.

That inversion is the difference between building the same integration three times and building it once. It also matches where the wider ecosystem landed: the Agent Plugins 1.0.0 specification, published a day before this preview with Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, treats exactly two things as portable across clients: skills and MCP servers. Agents, commands, hooks, and rules stay client-specific because their formats have not converged.

📝 Note

Agent Plugins is community-governed under its own charter, not an Agentic AI Foundation project, which is a distinction worth getting right. MCP itself is governed at AAIF, alongside Goose and AGENTS.md. The practical takeaway is that the MCP capability you author inside a plugin is the part with the longest shelf life.

You Describe the Capability, Not the Steps

Here is what changes most concretely for plugin authors. Wiring a remote MCP server into a Copilot experience used to mean reading the server’s docs, transcribing its tool names into a manifest, guessing at the auth shape, registering the plugin without typos, and discovering at runtime which of those five things you got wrong.

Now it is a sentence.

GitHub Copilot

Add our expenses MCP server at https://expenses.contoso.com/mcp to this plugin, then get it running in my dev tenant.

Connected to the server and completed the handshake before writing anything. It advertises three tools: list_expense_reports, get_reimbursement, and submit_expense.

Wired it in with those exact names, plus the OAuth configuration the server declared in its metadata. I did not invent a tool list from the docs.

One thing I flagged rather than fixed: submit_expense is side-effecting and your plugin gives the model no guidance about confirmation. I would rather you decide that than have me guess.

Validated: clean, 1 capability, 0 findings. Provisioned to your dev tenant.

Want me to add a confirmation guardrail for submit_expense before you test it?

Notice what happened in the middle. The handshake came first, so the capability got wired from what the server actually exposes rather than from a hand-copied list, which is the same failure mode dynamic tool discovery exists to close. And the one judgment call got surfaced instead of silently resolved.

💡 Tip

Point at a live endpoint before you ask for anything else. Discovery grounds every downstream step. If the server is not running yet, say so and let the plugin get scaffolded around a placeholder you fill in later.

Validation That Has an Opinion

Asking for validation gets you two different things. Schema checks tell you the JSON is well-formed. Referential checks tell you whether the plugin still describes reality, which is the class of bug that actually bites, because a manifest pointing at a tool that got renamed last sprint is perfectly valid JSON and a completely dead capability.

GitHub Copilot

My expenses agent is not calling the reimbursement tool. Figure out why.

The manifest is schema-valid, so this is not a JSON problem. I re-ran discovery against the server and compared it to what the plugin declares.

Two findings:

  1. The plugin declares getReimbursementStatus. The server now exposes get_reimbursement. The tool was renamed upstream, so the agent is advertising something that resolves to nothing.
  2. The description reads "Gets status." That is four words for the model to decide against calling. Nothing in it mentions expenses, reimbursement, or when it applies.

The first one breaks the call. The second one means the model never tries in the first place.

Want me to re-sync from discovery and rewrite the description using the vocabulary your users actually type?

That second finding is the one worth dwelling on. A schema validator has no opinion about a weak tool description. A workflow that understands why Copilot ignores plugins does, and that gap is the entire argument for the conversational surface being more than a friendlier wrapper.

One Loop, Not Ten Steps

Underneath the conversation there is a lifecycle, and the useful property is that it is a loop rather than a pipeline. You build, you get honest about quality, you put it in front of people, you ship it, and what you learn from real usage sends you back to the start.

Where you areWhat you ask forWhat you get back
Empty folder”Start a plugin for expense workflows”Conventions applied on day one instead of on plugin number four
Capability wiring”Add this MCP server”Live discovery, real tool names, auth shape read from the server
Quality gate”Is this actually good?”Referential validation plus generated evals with a pass bar
Trying it out”Ask it about last quarter’s reimbursements”The agent invoked from where you already are, no ID copy-pasting
Getting it to people”Package this” / “Deploy it” / “Share it”Three distinct acts kept distinct
Live”How is it doing?”Usage, health, and adoption without a portal tab

Keeping packaging, deployment, and sharing as separate asks is a deliberate correction. Those are three different acts with three very different blast radii, and tooling that merges them is how a dev build ends up in front of a tenant.

Quality Gets a Number

A plugin that works on the three prompts you thought of is not a plugin that works. As these move from demos into workflows people depend on, the only way to know whether last night’s instruction tweak helped is to have a score from before and a score from after.

Ask for evals and you get a suite generated from what your plugin actually declares: an MCP capability produces prompts that check tool selection, not just phrasing. They land as plain YAML in your repo, they run on demand, and they run the same way in a pull request as they do at your desk. If you have read why agents without evals are just vibes, this is that argument with the friction removed.

That last point is the one that makes this more than developer sugar. Every workflow you drive conversationally has a non-interactive equivalent with stable exit codes and machine-readable output, so the loop you run by hand is the same loop your pipeline runs on every change. Nothing gets reimplemented in bash.

📝 Note

WIQD sits on top of the Agents Toolkit rather than replacing it. Your m365agents.yml and appPackage/ layout stay exactly where they are, so adopting it on an existing project is additive rather than a migration.

The Value You Just Unlocked

  • Intent instead of invocation: Describe the capability you want and let the tooling pick the steps, in the order the platform actually requires.
  • The plugin as the durable unit: Author a capability once and compose it into multiple agent experiences instead of rebuilding the integration each time.
  • MCP capabilities grounded in reality: A live handshake writes the tool names, so nothing references a tool that does not exist.
  • Validation with an opinion: Renamed tools and descriptions too weak to trigger a call both get caught, not just malformed JSON.
  • Quality with a number attached: Generated eval suites that run identically at your desk and in a pull request.
  • The same loop end to end: Everything you can ask for conversationally has a non-interactive equivalent for CI.

The shift is not that any single step got easier. It is that the seams between the steps stopped existing, which is where plugin projects have been losing their afternoons.

Resources

Have questions or want to share what you're building? Connect with me on LinkedIn or check out more on The Manifest.