Building Plugins for Microsoft 365 Copilot Declarative Agents - A Practical Guide

Most organisations using Microsoft 365 Copilot hit the same wall within a few weeks. The out-of-the-box experience is fine for summarising emails and generating draft documents, but the moment someone asks "can Copilot check our project budget?" or "can it update our CRM?" - you're in extensibility territory.

Plugins are how you get there. They let declarative agents in Microsoft 365 Copilot talk to your own APIs and MCP servers, turning natural language prompts into actual operations against your systems. Not just reads - creates, updates, deletes. Anything your API can do, Copilot can now trigger through conversation.

We've been building these for clients across financial services, logistics, and professional services in Australia, and the pattern is consistent: once people see what's possible, the use cases multiply fast.

How Copilot Plugins Actually Work

The flow is straightforward, though there are details worth understanding.

A plugin provides a manifest file - essentially a description of what your API or MCP server can do. Copilot reads this manifest to understand the plugin's capabilities, then decides when to invoke it based on the user's prompt.

Here's the step-by-step:

1. A user asks something like "How much is left in the renovation budget?"
2. Copilot identifies that a budget-related plugin has the right capability - say a GetBudget function
3. It maps parts of the question to parameters (budget name, in this case)
4. Copilot asks the user for permission to send that data to the plugin
5. If the API requires authentication, the token store handles credentials
6. The request goes out to your API or MCP server
7. The response comes back, and Copilot generates a conversational answer

That permission step in point 4 is worth noting. Copilot won't silently send data to external systems. After the user confirms the first time, read-only operations stop asking, but anything that modifies data continues to require confirmation. You can customise these prompts, which matters for user experience in production.

MCP Servers vs REST APIs - Pick Your Path

Plugins support two connection types: MCP servers and REST APIs with OpenAPI descriptions.

REST APIs are the established path. If you've got an existing API with an OpenAPI spec, you're most of the way there. The plugin manifest maps natural language intents to API endpoints. A prompt like "Charge $500 to the Contoso travel budget" becomes a POST /budgets/charge with the right JSON body.

MCP servers are the newer option, and this is where things get interesting. MCP (Model Context Protocol) is becoming a standard for connecting AI models to tools and data sources. Instead of REST endpoints, you expose "tools" that Copilot can call. The same budget charge becomes a tools/call invocation with the tool name charge-budget and structured arguments.

For new builds, I'd lean towards MCP. The protocol is designed for AI-to-tool communication, so the abstraction fits better. For existing systems with established APIs, wrapping them with a plugin manifest is the path of least resistance.

There's also a preview feature for calling APIs in a local library using the Office JavaScript Library. It's experimental, so don't put it in production, but it's worth playing with if you're building Office Add-ins that need Copilot integration.

The Manifest File is Everything

Your plugin lives or dies by its manifest. This isn't just metadata - it's how the Copilot orchestrator decides whether your plugin is the right tool for a given prompt.

Think of it this way: Microsoft 365 Copilot has access to many skills and plugins. When a user asks a question, the orchestrator has to pick which skill to invoke. Your manifest descriptions are what make that selection work.

Bad descriptions lead to your plugin never being triggered, or being triggered for the wrong prompts. Good descriptions are concise, specific, and accurate. The plugin manifest schema documentation covers the format, but the principle is simple: describe what your plugin does in terms a non-technical user would understand.

We've seen clients spend days debugging "why isn't Copilot using my plugin?" and the answer is almost always the manifest descriptions. Write them like you're explaining the capability to a colleague who's never seen the system.

Practical Patterns We've Seen Work

Start with Read-Only

Every client we've worked with has been keen to jump straight to write operations. Don't. Start with queries. Let users search budgets, look up customer details, check order status. Get comfortable with the permission model, the response formatting, and the orchestrator behaviour before you add anything that changes data.

Read operations don't require repeated user confirmation after the first approval. Write operations do. That difference matters for adoption - if users are clicking "Allow" every 30 seconds, they'll stop using the plugin.

Adaptive Cards for Structured Responses

By default, Copilot generates conversational text from your API responses. That works for simple answers, but for anything with structure - tables, cards, actionable items - you want Adaptive Card templates.

The plugin can provide these templates, and Copilot will use them to present data in a structured way instead of just narrating it. Budget summaries look better as a card with a progress bar than as a paragraph of text.

Authentication Patterns

Plugins support OAuth and API key authentication through Microsoft's token store. The first time a user interacts with a plugin that requires auth, they'll be prompted to sign in. After that, the token store manages refresh and reuse.

For enterprise deployments, you'll want to think about which identity provider you're using and how that maps to your API's auth model. Single sign-on through Entra ID is the smoothest path for Microsoft-heavy environments.

URL Handling - A Gotcha Worth Knowing

URLs in plugin responses might render as clickable links in the Copilot chat, but this behaviour is controlled by the Copilot runtime and can change. The docs explicitly say not to rely on clickable URLs for production-critical scenarios.

If your workflow depends on users clicking through to a specific page, build that into an Adaptive Card button instead of hoping the URL in your JSON response gets rendered as a link.

Where This Fits in Your AI Strategy

Copilot plugins are one piece of a bigger picture. They're best for scenarios where users are already working in Microsoft 365 - Teams, Outlook, Word - and want to interact with business systems without switching context.

For more complex AI workflows that go beyond question-and-answer, you're looking at agentic automation patterns where AI agents orchestrate multi-step processes. And for organisations just starting to think about where AI fits, our AI strategy consulting work often starts with mapping out which touchpoints benefit most from AI integration.

The sweet spot for Copilot plugins is making existing business data and operations accessible through natural conversation. It's not about replacing your applications - it's about making them accessible from the place your team already spends most of their day.

Getting Started

If you've got an API with an OpenAPI spec, you're genuinely a few hours from a working prototype. The manifest authoring is the main work, and Microsoft's extensibility documentation covers the schema well.

For MCP-based plugins, factor in time for setting up the MCP server if you don't already have one. The protocol itself is simple, but you'll need hosting and the usual operational concerns.

We've been doing this work as Microsoft AI consultants for organisations across Australia, and the pattern is consistent: the technical build is straightforward, but the value comes from choosing the right use cases and writing good manifest descriptions. The technology is ready. The question is which business processes benefit most from being accessible through conversation.

If you want to explore what Copilot extensibility could do for your organisation, get in touch. We can usually identify the highest-impact use cases in a single workshop session.