What it does

A Microsoft 365 Copilot plugin can expose the tools of a remote MCP server. The plugin package holds only the connection settings; the server runs somewhere you host and secure. You register it in the root-level agentConnectors array of the Microsoft 365 app manifest, or let Work IQ Dev Tools generate and package that for you.

Key facts

• The schema key stays agentConnectors even though the shipped thing is called a plugin. Each entry needs a unique id, displayName, description and a toolSource.remoteMcpServer with an HTTPS mcpServerUrl and an authorization block.
• This is the app manifest route. It is not the MCP plugin manifest used for declarative agent actions, and it is not the Agent 365 CLI registration route. Support for MCP alone says nothing about support for this model.
• The server needs a public HTTPS endpoint, TLS 1.2 or later, and a transport the target experience supports.
• Authorization types: None, OAuthPluginVault, ApiKeyPluginVault, DynamicClientRegistration, AzureKeyVault (host support required) and ConnectionVault (developer preview schema only). A value existing in the schema doesn't mean the target experience honours it.
• referenceId points at a configuration registered separately in Developer Portal. Secrets never go in the manifest.
• OAuth needs https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect allowed as a redirect URI at your provider.
• Dynamic client registration uses RFC 7591, and Microsoft Entra ID doesn't offer a registration endpoint, so an Entra-protected server needs static OAuth registration.
• Tool discovery is either a packaged toolDescription.json or runtime tools/list. Omitting mcpToolDescription needs manifest version 1.29 or later and a host that supports it. Copilot Cowork still requires the file.

When to use / skip

Use it when you own or can host an MCP server and want its tools inside Copilot experiences under one packaged, versioned, admin-deployable plugin. Skip it if a single REST API is all you need, or if the experience you're targeting doesn't support agentConnectors, because the manifest will validate and then do nothing useful.

Configuration decisions

• Static tool definitions or dynamic discovery. Static gives you review control and Cowork compatibility; dynamic means the capability set can change without a package update.
• Authorization type, and where the credentials live. Prefer OAuth over API keys for anything per-user.
• Which target experiences you test in, since support varies per host.
• Whether you hand-edit the manifest or generate it with Work IQ Dev Tools.

Gotchas

• Static definitions drift. If the server adds or renames a tool and the packaged file doesn't follow, Copilot offers tools that no longer exist.
• Deployment and admin approval don't replace user sign-in, consent or the downstream service's own permissions. A green deployment can still return nothing for an unconsented user.
• A shared API key authenticates the plugin, not the person, so downstream permission trimming disappears.
• Test token refresh explicitly. Long sessions fail on expiry in ways a quick demo never shows.
• The manifest fragment in the docs is not a complete manifest. Merge it into the existing file and keep the other required properties.

Consultant notes

• Settle authorization before writing any tool code. Retrofitting per-user OAuth onto a server built around a service key is a redesign.
• Decide who owns the server's change control. The plugin is just a pointer, and whoever deploys the server decides what Copilot can do.
• Keep a test tenant with a consented user and a non-consented one. Most "it doesn't work" reports come down to consent or admin approval, not the manifest.
• Check which host you actually need before investing. Cowork's tool-description requirement alone changes how you package.

---

Worth revisiting as more Copilot experiences add agentConnectors support and the preview auth types settle.