Copilot Plugins: What They Are and Where They Run
A Microsoft 365 Copilot plugin does not run in Microsoft 365 Copilot. That reads like a typo, and it’s the first thing worth getting straight, because Microsoft’s own documentation states it in a note most people scroll past: “Plugins are only supported as actions within declarative agents. They are not enabled in Microsoft 365 Copilot.”
So if you’ve been looking for where to install a plugin into Copilot itself, there’s no such place. A plugin is something a declarative agent carries. Build the agent first, add the plugin as an action, then use the agent.
What a plugin actually is
A plugin lets a declarative agent talk to either an MCP server or a REST API with an OpenAPI description. Through it, the agent can query for information and also create, update, and delete records. Microsoft’s framing: “Anything the MCP server or REST API can do is accessible through natural language prompts.”
Every plugin ships a manifest that tells Copilot what its server or API can do, so the orchestrator can judge when the plugin fits a given prompt. Two tools generate the packages: the Microsoft 365 Agents Toolkit for Visual Studio and VS Code, which can build from an existing MCP server or OpenAPI description, and Kiota, a CLI and VS Code extension that generates from an OpenAPI description.
MCP plugins resolve their tools at runtime
This is the genuinely useful design decision, and it splits the two plugin types.
For an MCP-backed plugin, Copilot resolves the server’s tools dynamically at runtime, straight from the server. Ship a new tool on your MCP server and users get it without the agent being repackaged and republished. A developer can opt out by pinning a fixed tool set in the manifest.
REST API plugins always use the tools defined in the manifest. New endpoint means new manifest means republish.
Presentation follows the same split. MCP plugins can return rich interactive widgets using MCP apps, delivered alongside the tool result at runtime, which works whether the plugin pins tools or discovers them dynamically. API plugins use Adaptive Card templates declared in the manifest, an approach that also covers MCP plugins with a pinned tool set.
When it asks before doing something
Copilot prompts the user the first time any data is sent to a plugin. After that connection is confirmed, the split is what you’d hope: tools and APIs that only retrieve data run without confirmation, and ones that modify data ask. Plugin developers can override those defaults in either direction.
One caveat Microsoft flags directly: Copilot may render URLs returned in action responses as clickable links, and the runtime controls that behavior without evaluating it against any domains the plugin declares. Microsoft’s advice is not to rely on clickable URLs in action responses for anything production-critical.
Plugins, connectors, and agents are three different things
The Microsoft vocabulary is dense enough that people use these interchangeably and then wonder why their setup doesn’t work.
- Declarative agents are the configurable Copilot experiences: custom instructions, added knowledge, and actions. This is the container everything else plugs into.
- Plugins are actions. They reach outward to an MCP server or REST API to fetch data and make changes. They only exist inside an agent.
- Microsoft 365 Copilot connectors are knowledge. They bring external content into Copilot, and come in two models: synced connectors that ingest and index content into Microsoft Graph, and federated connectors that retrieve in real time over MCP without indexing anything into Graph.
- Copilot connectors in the Copilot Studio sense are a separate lineage again, reaching Power Automate, Power Apps, and Azure Logic Apps as well as Copilot. Roughly 90 of them ship in the admin center gallery.
A plugin does; a connector knows. If your agent needs to search your document store, that’s a connector. If it needs to charge a budget, that’s a plugin.
The caps Microsoft publishes
Real numbers from the documentation, worth knowing before you design an agent around a dozen integrations:
- Five is the threshold. With up to five plugins in the declarative agent manifest, the agent injects all of them into the prompt. Past five, it switches to semantic matching.
- Semantic matching reads the plugin description only, not the individual functions or tools inside it. Your plugin description is doing all the selection work.
- A matched plugin returns all its tools, even if only one matched. A plugin can hold unlimited functions or MCP tools, and for dynamic discovery the runtime-resolved tools count toward that total.
- Past roughly 10 functions or tools, response quality may degrade because of token window limits.
- Large content gets truncated in both directions through the plugin token window.
The practical read: several small, sharply described plugins beat one sprawling plugin, and a plugin description written as an afterthought is the most common reason the orchestrator never picks it.
What none of this covers
Everything above describes an agent responding to a prompt. A user asks, the orchestrator picks a plugin, the plugin calls out, Copilot answers.
Scheduled work is no longer the dividing line — ChatGPT and Claude both run tasks on a timer without anyone watching. The line that still holds is event triggers. Nothing kicks off because something happened in one of your apps; it kicks off because the clock said so, which means anything time-sensitive waits for the next run.
Nothing in the plugin model watches an external system. There’s no manifest field for “when a record changes,” and dynamic tool discovery, useful as it is, resolves tools at the moment of a request rather than noticing anything on its own. The MCP side inherits the same constraint the protocol has everywhere:
MCP has no trigger mechanism and no scheduler. Its own Triggers and Events working group opens by conceding that clients learn about server-side changes by polling, and that work is still listed as on the horizon rather than shipped.
Which means the expensive failure isn’t a plugin that answers badly. It’s the Friday afternoon where the budget was overspent, the ticket went unanswered, or the deal closed, and the agent that could have handled all three was sitting there waiting for someone to open a chat window.
The piece that starts the work
Carly fills that specific hole. It connects natively to roughly 260 apps and to anything else with a public API through your own key on the integrations dashboard, and its workflows begin on an event or a schedule rather than a prompt:
- When a deal is marked won in your CRM, create the onboarding doc, post it to the right channel, and schedule the kickoff call.
- Every Monday at 8am, pull last week’s numbers into a sheet and send the summary.
- When an invoice goes overdue, draft the follow-up, log the task, and notify the owner.
No agent manifest, no toolkit, no five-plugin threshold to design around. Carly is free for Zapier-style workflows, with AI agents from $35/month.
Copilot plugins are the right tool for letting an agent reach your systems during a conversation. Carly is the right tool when the work needs to happen whether or not that conversation ever starts. If you’re weighing the wider Copilot picture, Microsoft Copilot alternatives covers the rest of the field.
FAQ
Can I install a plugin directly into Microsoft 365 Copilot? No. Microsoft’s documentation states that plugins are only supported as actions within declarative agents and are not enabled in Microsoft 365 Copilot. You add the plugin to an agent, then use the agent.
What’s the difference between a Copilot plugin and a Copilot connector? A plugin is an action: it calls an MCP server or REST API to fetch data and make changes. A connector is knowledge: it brings external content into Copilot, either by indexing it into Microsoft Graph or by retrieving it in real time over MCP without indexing.
Do I need to republish my agent when I add a tool to my MCP server? Not if the plugin uses dynamic tool discovery, which is the default for MCP-backed plugins. Copilot resolves the server’s tools at runtime. If the developer pinned a fixed tool set in the manifest, or the plugin is REST-based, you do need to republish.
How many plugins can one declarative agent have? There’s no hard cap, but behavior changes at five. Up to five, all plugins are injected into the prompt. Beyond that, the agent uses semantic matching against plugin descriptions, and quality can degrade past roughly 10 total functions or tools.
Can a Copilot plugin run on a trigger? No. Plugins execute as actions inside a prompt-driven conversation with an agent. For work that starts when something changes in one of your systems, or on a schedule, you need an automation layer such as Carly.
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
