Work IQ Developer Tools: Bringing MCP Servers to Copilot

Work IQ Developer Tools (WIQD) is Microsoft's packaging layer for turning an existing agent capability, including an MCP server you already run for Claude or another agent harness, into a Microsoft Copilot plugin that shows up in the Copilot plugin registry. If your MCP server already works with an OAuth-based agent client, WIQD is usually a packaging and auth-remapping exercise, not a rebuild.

Microsoft announced WIQD in late September 2026, the same week its SharePoint Framework roadmap update confirmed that new Copilot UX components are heading to general availability in October 2026. Put together, those two posts say Microsoft wants both the Copilot surface and the Copilot developer tooling to mature at the same time. For ISVs that already ship an MCP server for Docusign IAM, NetSuite, or Zoho CRM integrations, that's the moment to treat Copilot as a second distribution channel instead of a second codebase.

What Is Work IQ Developer Tools (WIQD)?

WIQD is a CLI and workflow, built on top of the Microsoft 365 Agents Toolkit, for scaffolding, validating, provisioning, and packaging Microsoft Copilot plugins. A plugin in this context is a bundle of one or more capabilities, skills, remote MCP connectors, or declarative agents, described in a Microsoft 365 app manifest. You can start from scratch with natural-language prompts, or you can import an existing MCP server you already run for another agent client and have WIQD generate the surrounding manifest, skill files, and connector descriptors around it.

That second path is the one that matters for integration teams. If your MCP server already exposes tools for reading Docusign envelopes, querying NetSuite records, or writing Zoho CRM leads, you are not writing a new API surface for Copilot. You are writing a manifest that points at the MCP endpoint you already run.

How Does WIQD Package an MCP Server for Copilot?

The typical flow, once you have an MCP server running, looks like this:

wiqd plugin validate runs locally first and checks the declarative-agent artifacts and manifest shape before anything touches your tenant. wiqd plugin provision registers the plugin's connectors and skills in Microsoft 365. wiqd plugin package builds the installable Microsoft 365 app package, and wiqd plugin validate --mode deep checks the packaged manifest against the live registry rules, including authentication wiring.

An MCP server is declared inside the manifest's agentConnectors array, pointing at a remoteMcpServer runtime rather than a REST API spec. That is the structural reason reuse works: Copilot's plugin schema was built to reference an MCP endpoint directly, so the integration logic you already wrote for Claude or another MCP client does not need to be reimplemented, only re-described.

One useful side effect: the same wiqd project can target more than one agent harness. The Copilot Cowork developer docs note that a plugin authored with wiqd can be exported to a Claude Code plugin layout with a single wiqd plugin export --format claude-plugin command. If you are already maintaining SKILL.md-style skills for Claude, you do not have to fork them to also ship on Copilot.

Does an Existing MCP Server Need Changes to Register as a Copilot Plugin?

Usually yes, specifically around authentication, even if nothing about the server's actual tool logic changes.

Microsoft's own MCP server documentation is direct about this: for any MCP server that requires authorization, the manifest's runtime authentication type has to be set to OAuthPluginVault or DynamicClientRegistration. None and ApiKeyPluginVault are explicitly unsupported for an MCP server that needs authorization. That is a Copilot-specific constraint, not a Model Context Protocol constraint, and it is the single most common reason a server that works fine with another MCP client fails WIQD's deep validation on first try.

Under the hood, this means:

• Entra SSO (sign in the current Microsoft 365 user) wires through a generated _MCP_AUTH_ID referenced by OAuthPluginVault in the manifest, with the actual OAuth configuration registered via m365agents.yml so the Agents Toolkit provisions it in the Teams Developer Portal, per Microsoft's work-iq reference docs.
• Third-party OAuth (your MCP server talks to its own identity provider, not Entra) uses the same OAuthPluginVault reference point, but you register the client against your own authorization server first, then point the vault entry at it.
• If your server was built for an MCP client that expects plain bearer tokens or long-lived API keys with no refresh flow, that pattern has no supported slot in the Copilot plugin manifest once authorization is required. You will need to add a proper OAuth or Entra SSO layer before wiqd plugin validate --mode deep will pass.

If you are also targeting Copilot Cowork specifically, there is a second gotcha: Cowork needs a checked-in tool-description file capturing your server's tools/list output, passed via --tool-description. Skip it and, per Microsoft's MCP server guidance, "the package can pass WIQD validation but fail connection verification in Cowork". The plugin looks valid and still doesn't connect, which is a frustrating failure mode to debug blind if you don't know to check for it up front.

Where This Breaks: Auth Re-Validation, Not a Rebuild

The pattern that emerges from Microsoft's own docs and from early adopters is consistent: WIQD does not ask you to reimplement your MCP server's business logic. It asks you to re-validate the auth path against Copilot's specific manifest schema. A public, community ServiceNow MCP integration that added a WIQD packaging path described this directly in its own project notes, pointing to the official WIQD announcement post, and said the new path "does not replace the existing...package, does not change the MCP server runtime," with all packaging paths calling the same MCP endpoint so auth and caller mapping stay identical. That is the shape of a well-executed WIQD migration: one MCP server, two or three manifests, no duplicated backend.

The practical checklist before you attempt a WIQD import of an existing server:

1. Confirm the server already implements OAuth 2.0 (not just an API key) if it requires authorization at all.
2. Decide whether Copilot users will sign in with their Microsoft 365 identity (Entra SSO) or a separate account on your platform (third-party OAuth), because the manifest wiring differs.
3. Capture a current tools/list snapshot if Copilot Cowork is a target surface, not just Copilot chat.
4. Run wiqd plugin validate locally before provisioning anything in the tenant, so a failed auth assumption doesn't cost you a round trip through the registry.

What This Means for Docusign IAM, NetSuite, and Zoho CRM MCP Servers

This is where the distribution-channel framing pays off for ISVs and integration teams working with the platforms fluidlabs builds on. If you already maintain an MCP server for Docusign IAM agentic workflows, or for NetSuite data access alongside Docusign Workflow Builder (formerly Maestro), WIQD's import path means Copilot is a packaging target, not a second integration you have to design, build, and maintain separately.

The part that is easy to underestimate is exactly the auth layer described above. A Docusign-facing MCP server built against Docusign's own OAuth flow (see the Claude + Docusign MCP connector guide) is already OAuth-based, which is the right starting shape for a Copilot OAuthPluginVault entry. But the vault entry, the Entra app registration if you want Entra SSO, and the manifest's agentConnectors block are new artifacts you still have to build and test, even though the underlying Docusign calls don't change.

It's also worth being precise about what WIQD does not solve. It packages and registers a plugin; it does not make your MCP server's upstream webhook delivery more reliable. If the workflow you're exposing through Copilot ultimately kicks off a Docusign Workflow Builder run triggered from a CRM or ERP event, the reliability of that trigger, retries, HMAC verification, and logging, is a separate concern. That's the production layer Baton exists to handle for Docusign Workflow Builder specifically; WIQD and Baton solve adjacent but different problems; one gets your capability in front of Copilot users, the other keeps the webhook-driven trigger underneath it from silently failing.

WIQD Import vs Building a Native Copilot Plugin From Scratch

	Import existing MCP server via WIQD	Build native Copilot plugin
Backend logic	Reused as-is	Written new
Auth work	Re-map to OAuthPluginVault / DynamicClientRegistration	Designed from zero against Copilot's manifest schema
Maintenance surface	One MCP server, multiple manifests	Separate codebase to keep in sync
Best fit	You already run an MCP server for Claude or another harness	Copilot is your only or primary target client

For nearly every ISV already shipping an MCP server for a proven integration platform, the import path is the lower-cost, lower-risk route. The cost isn't zero, mostly concentrated in auth re-validation and manifest correctness, but it is a packaging cost, not a development cost.

FAQ

Does Work IQ Developer Tools require rewriting my MCP server? No. WIQD's import path wraps an existing MCP server in a Microsoft 365 app manifest and registers it as a plugin connector; the server's own tool implementations don't change, per Microsoft's WIQD announcement.

Can an MCP server built for Claude also work with Microsoft Copilot? Yes, through WIQD's import and packaging flow, and the reverse is also supported: a plugin authored with wiqd can be exported to a Claude Code plugin layout with wiqd plugin export --format claude-plugin, per Microsoft's Copilot Cowork plugin docs.

What authentication does a Copilot plugin need for an MCP server? Any MCP server that requires authorization must use OAuthPluginVault or DynamicClientRegistration in the manifest's runtime authentication type; None and ApiKeyPluginVault aren't supported for servers that need authorization, per Microsoft's OAuth 2.0 configuration docs.

Why would a WIQD-packaged plugin pass validation but still fail to connect in Copilot Cowork? Cowork specifically needs a checked-in tool-description file built from the server's tools/list output; without it, a package can clear WIQD validation and still fail Cowork's own connection verification, per Microsoft's MCP server build-or-reuse guidance.

The next step

If your team already runs an MCP server against Docusign IAM, NetSuite, Zoho CRM, or another proven integration platform, the WIQD import path is worth a scoping pass before anyone commits to a native Copilot build. The work that actually takes time is the auth re-mapping, not the connector logic. Talk to the fluidlabs team about scoping that auth path, or browse the rest of our Docusign IAM resources for related integration patterns.