The Copilot Plugin Manifest 2.3 - What Changed and Why It Matters for Your Extensions
If you have built anything for Microsoft 365 Copilot, you already know that the interesting work is not the model, it is the plumbing. Getting Copilot to reliably call your API, understand what your plugin does, and surface the right thing at the right moment comes down to a document most people never think about: the plugin manifest. It is the contract between your extension and Copilot, and Microsoft keeps evolving it. The version 2.3 plugin manifest is the current schema, and if you are building declarative agents or API plugins, this is the file you live in.
I want to walk through what the manifest actually does, what version 2.3 brings, and the practical lessons we have picked up building Copilot extensions for Australian clients. Some of this is genuinely good and some of it is still rough, and I will tell you which is which.
What the manifest actually is
Strip away the jargon and the plugin manifest is a JSON file that tells Copilot three things: what your extension is, what it can do, and how to talk to it. It describes the functions your plugin exposes, the parameters each one takes, how Copilot should authenticate, and most importantly, the natural-language hints that help Copilot decide when your plugin is the right tool for a user's request.
That last part is the bit people underestimate. Copilot is not reading your API documentation. It is reading the descriptions in your manifest and using them to reason about whether your plugin can help with what the user just asked. Vague descriptions produce a plugin that never gets called, or worse, gets called at the wrong moment and returns nonsense. The manifest is where the quality of your extension is won or lost, and it has very little to do with how clever your backend is.
The schema version, 2.3 in this case, sets the shape of that file. Each version tightens definitions, adds capabilities, and occasionally deprecates things. Getting the version right matters because Copilot validates against it, and a manifest that references features from the wrong version will fail in ways that are annoying to debug.
What version 2.3 brings to the table
The 2.3 schema is an incremental step, not a rewrite, which is the right way to evolve something teams depend on. The theme across recent manifest versions has been giving developers more precise control over how functions are described, invoked, and rendered, plus better handling of authentication and response formatting.
The parts I would pay attention to are the richer function definitions and the improved control over how responses come back to the user. When Copilot calls your plugin and gets data back, you want control over how that data is presented, whether as a card, formatted text, or something the user can act on. The manifest is where you specify that, and the more recent schemas give you finer control. Adaptive Cards support in particular is where a plugin goes from "returns a wall of JSON-flavoured text" to "returns something a user actually wants to look at".
Authentication handling is the other area worth your time. Copilot extensions have to authenticate to your backend somehow, and the manifest describes that flow. Getting this right, with the correct auth type and cleanly scoped permissions, is the difference between a plugin your security team approves and one they veto. In an enterprise Microsoft environment, and especially in regulated Australian sectors, the auth configuration gets scrutinised, so treat it as a first-class part of the build rather than an afterthought.
The honest assessment
Here is where I will be straight with you, because the marketing around Copilot extensibility is enthusiastic and the reality is more textured.
The good part is genuinely good. When a Copilot plugin works, it is a lovely experience. A user asks a question in plain English, Copilot works out that your plugin can answer it, calls your API, and presents the result inline. No context switching, no separate app, no training. For the right use case, particularly surfacing data from a line-of-business system that people currently have to log into separately, it is a real productivity win.
The rough part is the debugging loop and the non-determinism. Because Copilot decides when to call your plugin based on natural-language reasoning, you can write a perfectly valid manifest and still find your plugin gets invoked inconsistently. Slightly reword a function description and the behaviour changes. This is the nature of building on top of a model, and it means testing a Copilot extension is more like tuning than traditional software testing. You need to try lots of real phrasings, watch what Copilot does, and iterate on the descriptions. Teams that expect deterministic "if I send this request I get this response" behaviour get frustrated fast.
The other thing to watch is that the manifest schema moves. Version 2.3 is current now, but Microsoft ships new versions, and features get added and occasionally deprecated. If you are building something you intend to maintain, factor in that you will be updating the manifest over time. This is not a set-and-forget artefact. It is a living contract that tracks a platform that is still very much in motion.
Lessons from actually building these
A few things we have learned the hard way that will save you time.
Spend real effort on your function descriptions. Write them the way you would explain the function to a colleague who has never seen your system, in natural language, being specific about what it does and what it returns. This is the highest-value work in the whole manifest and it is the thing people rush. If Copilot is not calling your plugin when it should, the description is almost always the culprit before anything else.
Keep your functions focused. A plugin with one function that does five things is harder for Copilot to reason about than five clearly named functions that each do one thing. Copilot matches user intent to function, so the more each function maps to a clear intent, the better the matching works.
Test with the phrasings your actual users use, not the phrasings you would use as the developer who built it. There is always a gap between how the person who wrote the API thinks about it and how the person in accounts payable asks for the same thing. Close that gap by testing with real language from real users.
Get authentication and permissions scoped tightly from day one. It is much easier to build with least-privilege access from the start than to walk it back after your security team flags it in review. This matters even more in the kind of enterprise Microsoft environments we work in across Australian organisations, where the Copilot rollout and its extensions get looked at carefully before they go anywhere near production.
Where this fits
If you are running Microsoft 365 and you are serious about Copilot, extensibility is where the platform goes from a general assistant to something that knows about your business. That is the whole point. A stock Copilot is useful; a Copilot that can pull from your CRM, your project system, or your line-of-business database is a different proposition. The manifest is the doorway to that, and building good extensions is a real skill that sits somewhere between API design and prompt engineering.
We do this work with clients through our Copilot Studio consultants and more broadly as part of Microsoft AI consulting, and the projects that succeed treat the manifest as a design problem, not a config file to fill in at the end. If your team is skilling up on this, our Copilot training covers the practical side of getting extensions working in a real environment rather than a demo.
The bottom line
The version 2.3 plugin manifest is a solid, incremental improvement to the contract that powers Copilot extensions. It gives you better control over functions, responses, and authentication, and it is the file where your extension's quality is genuinely decided. The technology is real and the good use cases are very good. Just go in knowing that building on top of a reasoning model means tuning rather than deterministic testing, that your function descriptions matter more than your backend, and that the schema will keep moving under you. Build accordingly and you will get a lot of value out of it.
If you want help designing Copilot extensions that actually get used, get in touch and we will talk through what makes sense for your setup.
Reference: Microsoft 365 Copilot plugin manifest schema 2.3, Microsoft Learn.