First Look: Extending Microsoft Copilot with the New Plugin Registry

By Jeff, Microsoft Ecosystem

Microsoft Copilot is becoming the central workspace where people ask questions, build apps, and delegate work to agents. Last week's redesign introduced Home, Code, and Autopilot as the three main surfaces. This week, Microsoft added the missing piece that makes those surfaces extensible: the Microsoft Copilot plugin registry. It is a single place to discover, publish, manage, and govern the plugins that give Copilot access to your organization's knowledge, tools, and workflows.

For IT admins, the registry means centralized control over what Copilot can reach. For developers and makers, it means one package can surface skills, connectors, and agents across Home, Code, Autopilot, Microsoft 365 apps, and SharePoint. For end users, it means a consistent Plugins menu instead of hunting through separate Agents pages.

Here is what the registry actually is, how it fits together, and how to start using it without turning your Copilot tenant into the Wild West.

What the plugin registry changes

Before the registry, Copilot extensibility lived in several places. Agents had their own page, skills were tucked into different admin experiences, and connectors were managed separately. The plugin registry unifies those capabilities into one model: a plugin is a package that can contain skills, connectors, and agents, along with the metadata needed to connect to MCP servers and other approved tools.

The top-level UI is changing too. The old Agents button is becoming a Plugins button in supported Copilot experiences. Users still get to all their agents; they also get skills and connectors in the same menu. Admins see the same plugins under Agents > Tools in the Microsoft 365 admin center, where they can approve, assign, block, or retire them by user or group.

Microsoft says more than 100 plugins are already available from partners such as HubSpot, Linear, Atlassian, Asana, Webflow, Canva, Notion, MongoDB, IDC, NielsenIQ, and CAS. More are being added. That is a lot of new capability arriving quickly, which makes governance even more important than discovery.

What is inside a plugin

A plugin is basically a portable unit of Copilot capability. It can include:

• Skills: reusable instructions that teach Copilot how to do specialized work, such as writing in a particular format or following a company-specific process.
• Connectors: approved bridges to services and data sources, so Copilot can read and act on information from tools like CRM, project management, or research platforms.
• Agents: customized Copilot experiences for specific jobs, such as onboarding a new hire, triaging a support queue, or preparing a quarterly business review.

The registry lets developers package these together, publish once, and update centrally. IT reviews each plugin once and decides who can use it. That is a big improvement over maintaining separate artifacts for every Copilot surface.

A nice practical detail: plugins can also connect to MCP servers. MCP, the Model Context Protocol, is becoming the standard way for AI agents to discover and call tools. Microsoft is making MCP servers a first-class tool type in the registry alongside skills, connectors, and agents. If you have an MCP server that exposes your internal service, you can wrap it as a Copilot plugin and give business users natural-language access to it.

How to build an MCP plugin

Microsoft Learn already has a walkthrough for creating a declarative agent with an MCP plugin using the Microsoft 365 Agents Toolkit in Visual Studio Code. The example uses the GitHub MCP server, but the same pattern works for any remote MCP server.

The high-level flow is straightforward:

1. Create an OAuth client for authentication with the MCP server.
2. Create a declarative agent and add an MCP plugin that points to the server.
3. Provision and sideload the agent for testing.
4. Try it from Copilot by asking natural-language questions that the MCP server can answer.

The plugin manifest is the key file. It tells Copilot where the MCP server lives, how to authenticate, and what it can do. The MCP server itself continues to run wherever you already host it; the plugin is the bridge that brings its tools into Copilot with the right governance wrapper.

Microsoft also supports dynamic tool discovery for MCP plugins. Instead of hardcoding a fixed list of tools in the manifest, Copilot can ask the MCP server at runtime what tools are available. That is useful when your service's capabilities change frequently, because the plugin does not need to be repackaged every time a new tool appears.

Governance: the part that matters most

The registry is exciting, but the real value is governance. Copilot becomes more useful when it can reach more systems, yet every connection is also a potential permission boundary. The registry addresses this by putting IT in the center of the decision.

From the Microsoft 365 admin center, under Agents > Tools, admins can:

• Review Microsoft, partner, and custom-built plugins in one inventory.
• Enable or disable plugins globally or for specific users and groups.
• Block plugins that do not meet security or data-residency requirements.
• Assign plugins based on role, so only the right people can invoke sensitive tools.
• Track usage and versions, making it easier to retire or update plugins over time.

This is the right model for enterprise AI: users get a growing catalog of approved capabilities, and IT keeps a single pane of glass. The registry also supports lifecycle management. As your organization changes, you can adjust assignments, review new plugin versions, and decide when to expand or narrow access without touching each underlying agent or connector separately.

A practical rollout plan

If you are an IT admin or a Copilot champion, here is a low-risk way to start:

1. Audit what is already enabled. Look at existing agents, skills, and connectors before the registry rolls out, so you understand the baseline.
2. Pilot with a small group. Enable a few Microsoft or partner plugins for a pilot security group. Watch what people ask for and whether the plugin delivers useful answers.
3. Document your approval criteria. Decide what makes a plugin acceptable: data handling, vendor reputation, required permissions, and alignment with compliance obligations.
4. Build one custom plugin. Pick a well-scoped internal process, such as looking up an employee's department from a directory or surfacing a support ticket status. Wrap it as an MCP plugin and publish it privately.
5. Review weekly at first. Plugin catalogs change quickly. A short weekly review lets you catch new submissions, version updates, and unexpected usage patterns before they spread.

If you are a developer, the same plan applies from the other side. Start by identifying one small, high-value tool or data source in your organization. Build an MCP server for it, package it as a plugin, and work with IT to get it approved. A narrow first plugin is much easier to govern than a broad integration.

How this connects to the bigger Copilot picture

The plugin registry is not an isolated feature. It ties together several recent Microsoft announcements:

• Home, Code, and Autopilot now share a common plugin catalog, so users see the same approved capabilities across chat, app building, and autonomous agents.
• Copilot Managed Runtime, in public preview, hosts and governs the code that Copilot creates inside the Microsoft 365 tenant boundary. Apps built with Code can use the same identity, policies, and connectors as plugins from the registry.
• Microsoft Foundry provides the model-agnostic agent foundation behind many of these experiences, including the latest frontier models and voice-agent support. A plugin built for Copilot can leverage Foundry's models without being locked to one provider.

Together, these pieces form a coherent extensibility story. Copilot is the user experience. The registry is the catalog. Managed Runtime and Foundry are the execution layer underneath. Organizations can add capabilities, control them centrally, and run them on Microsoft-managed infrastructure.

Bottom line

The Microsoft Copilot plugin registry turns extensibility from a scattered set of features into a governed, discoverable catalog. For the first time, skills, connectors, agents, and MCP servers can be packaged, published, and managed in one place, with consistent admin controls across Copilot experiences.

You do not need to rebuild your Copilot strategy to take advantage of it. Start small: audit what you have, pilot a few plugins, build one MCP-based plugin for a focused internal need, and use the admin center to keep control as the catalog grows. The registry makes it easier to give Copilot the context it needs to be genuinely useful, while keeping IT firmly in charge of what it is allowed to do.

---

Have you published a plugin, or are you planning your first MCP-based Copilot extension? Drop your scenario in the comments — I would love to hear what you are building.