What it does

A plugin is the wrapper that brings supported capabilities together — a declarative agent, a skill, a Copilot connector, an MCP server — and gives them one versioned package, a publishing route and a management lifecycle. It doesn't change how any of those components runs. Each is still built, hosted and supported the way it was before.

Key facts

• Four capability types sit inside the model: declarative agent (goal-directed experience), skill (reusable instructions or workflow), Copilot connector (approved external content), MCP server (remote tools and resources). A plugin can carry one or several.
• The package is the versioned artifact you validate, publish and update. It describes and connects components; it doesn't contain their runtime. A remote MCP server's configuration can ride in the package while the server runs somewhere else entirely.
• A plugin registry is shared infrastructure for registering and distributing plugins. Registration doesn't replace product-specific administration — availability, access, tools, connections and data each keep their own control surface.
• Connectors come in two shapes: synced (content ingested and indexed in Microsoft Graph) and federated (retrieved in real time, not indexed). Which one you need drives freshness, residency and what the target experience supports.
• Skill support is the thinnest of the four. Current Microsoft guidance mostly covers adding skills to agents; it doesn't promise every skill can be packaged or distributed on its own.
• Support for components, packages, publishing routes and admin steps varies by product and rollout. Microsoft repeats this caveat on almost every page in the set.
• The lifecycle runs: prepare, build or reuse, package and test, publish, make available and govern, then monitor, update and retire.

When to use / skip

Use the plugin model when the solution has more than one moving part and you want a single thing to version, publish and retire — an agent plus a connector plus a skill for one business scenario, say. It earns its keep in the governance conversation, because there is one named object to approve.

Skip it for a single agent built and shared inside one team. Agent Builder sharing or an org catalog submission is a shorter road, and wrapping a lone agent in plugin vocabulary adds process without adding control.

Configuration decisions

• Which components, and the smallest set that does the job. Microsoft's own advice is not to add a component because a tool happens to support it. Map each requirement to one component or to an identified gap.
• Build, reuse, extend or configure. Check approved existing components first, and confirm the owner supports your audience and lifecycle before you depend on them.
• Who owns each component and its dependencies. Identity, permissions, consent, hosting and support contacts, written down per component, before packaging starts.
• Connector model. Synced versus federated, prebuilt versus custom. Settle it against freshness and data-residency needs, not against how pleasant the build is.
• Target experiences. Decide which Microsoft 365 experiences must be supported at the start. A route that works for one host may not exist for another.

Gotchas

• Publishing doesn't make a plugin usable. Review, acquisition, assignment, enablement and connection depend on the route and the components, and they don't happen as a single step. Plan the post-publish work as its own phase.
• Packaging MCP connection details doesn't make the plugin publisher responsible for the MCP server, and equally doesn't make the server the publisher's to fix. If somebody else runs it, their uptime is your uptime.
• Components can show up in admin inventories independently of any plugin, with their own administration requirements. A governance process that only watches plugins will miss them.
• A plugin package for one combination of components isn't automatically valid for another. A .zip that works for an agent isn't a plugin package for every mix.
• Agents take part in the plugin model differently depending on agent type, package, route and experience. Read the publishing page for your agent type rather than assuming parity.

Consultant notes

• The first workshop question is "which of these four are we actually building?" Clients arrive saying "plugin" and mean one agent. Get the component map on a page early; it settles scope, owners and the route in one go.
• Ownership of the remote service is where these projects stall. A skill and a connector have clear builders; the MCP server often belongs to a vendor or another internal team with no agreement about support hours. Get that conversation done before UAT.
• Write the publishing-and-availability steps into the project plan as tasks. Teams treat "published" as go-live, then discover an administrator still has to review, assign and connect it, and the date slips by a sprint.
• Keep the component dependency record as a living artefact. It is what the administrator needs at handover and what you'll want when something breaks eight months later.

---

Microsoft published this plugin guidance set on 30 September 2026 and parts of the tooling are alpha — worth revisiting after the next Copilot extensibility update.