Building MCP Plugins for Microsoft 365 Copilot - A Practical Guide

The Model Context Protocol (MCP) has been one of the most talked-about developments in the AI tooling space over the past year. If you've been following along, you'll know MCP gives AI models a standardised way to connect to external services and data sources. What you might not know is that Microsoft has now brought MCP support directly into Microsoft 365 Copilot through declarative agents.

This is a big deal for Australian organisations already invested in the Microsoft ecosystem. It means you can take existing MCP servers - or build new ones - and wire them into Copilot so your business users get AI-powered access to those services without leaving their normal workflow. No custom app required. No training users on a new interface.

I've been working with several organisations to explore this capability since it entered public preview, and I want to walk through what the experience actually looks like, where it works well, and the bits that still need polish.

What This Actually Gives You

The basic idea is straightforward. You create a declarative agent in Copilot, point it at an MCP server, and select which tools from that server you want your agent to use. Users then interact with the agent through the normal Copilot chat interface, and the agent calls your MCP server behind the scenes.

Think about what that means in practice. Say your team already has an MCP server that talks to your project management system. Instead of building a separate chat interface, you can wire it into Copilot and let people ask questions like "what's the status of the Henderson project?" right from their Microsoft 365 workspace. The MCP server handles the API calls, Copilot handles the conversation, and the user gets an answer without switching context.

The integration works through the Microsoft 365 Agents Toolkit in VS Code, which handles the scaffolding and deployment. You select "Declarative Agent", choose "Start with an MCP Server", enter your MCP server URL, and the toolkit generates everything you need.

The Setup Process

I'll be honest - the setup is more involved than I'd like, but it's manageable once you've done it once. Here's what the process looks like:

Prerequisites you'll need sorted first:

• A Microsoft 365 account with Copilot access and custom app upload enabled
• Visual Studio Code with the Microsoft 365 Agents Toolkit (version 6.3.x or later)
• Your MCP server URL

The Agents Toolkit walks you through creating the project. You pick "Declarative Agent", select "Add an Action", then "Start with an MCP Server". Enter your server URL and the toolkit generates the project files.

Once the project is created, you open .vscode/mcp.json and use the "ATK: Fetch action from MCP" button to pull in the available tools from your MCP server. This is where you choose which operations your agent can perform. You don't have to expose everything - pick the operations that make sense for your users.

A word on authentication. The current preview supports OAuth with static registration. If your MCP server uses a different auth method, you'll need to adapt. For the GitHub example Microsoft provides, you register an OAuth app at github.com/settings/developers and set https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect as the callback URL. The client ID and secret get entered during the provisioning step.

Then you provision through the Agents Toolkit, which packages everything and sideloads it into your Microsoft 365 environment. Your agent shows up in the Agents section of the Copilot sidebar with "dev" appended to the name.

What Works Well

The user experience is genuinely good. Once the agent is set up, your users don't need to know anything about MCP servers or APIs. They just ask questions in natural language and get answers. I watched a project manager query a GitHub repo through one of these agents without any idea that an MCP server was involved. That's exactly what you want.

Tool selection is sensible. You don't have to expose every capability your MCP server offers. If your server has 20 tools but your users only need three, you can select just those three. This keeps the agent focused and reduces the chance of unexpected behaviour.

It builds on existing investments. If your organisation has already built MCP servers for use with other AI tools (Claude, custom applications, whatever), you can potentially reuse those same servers with Copilot. That's real value - you're not rebuilding integrations from scratch.

Where You'll Hit Friction

Preview quirks are real. The manifest validation can fail for certain parameter types. Nested objects and properties with minimum, maximum, or default values can cause the provisioning step to choke. You'll need to strip those out and retry. Microsoft documents this, but it's still annoying when you hit it with your own MCP server definitions.

Only tools are supported. If your MCP server exposes resources or prompts alongside tools, Copilot will only see the tools. This might mean restructuring how your MCP server presents certain capabilities.

Auth complexity. OAuth with static registration works, but many real-world MCP servers use different authentication approaches. If your server uses API keys, custom tokens, or service-to-service auth, you'll need to figure out how to wrap that in OAuth. Not impossible, but it adds a layer of work.

Debugging is limited. When something goes wrong between Copilot and your MCP server, troubleshooting can be frustrating. The error messages aren't always helpful, and there's no easy way to inspect what's happening in the middle of the chain. I'd recommend getting your MCP server thoroughly tested independently before trying to wire it into Copilot.

When Should You Actually Use This?

Not every MCP server should become a Copilot plugin. I'd focus on scenarios where:

1. Your users are already in Microsoft 365 most of the day
2. The queries are conversational - things people would naturally ask in chat
3. The underlying service has relatively simple request/response patterns
4. You want to reduce context-switching between different tools

If your use case involves complex multi-step workflows with lots of back-and-forth, you might be better served by a purpose-built application or a more sophisticated agent framework.

For Australian organisations in the Microsoft ecosystem, though, this is worth experimenting with. The ability to give business users natural language access to your internal systems through a tool they already use every day - that's genuinely useful.

Getting Started

If you want to explore this, I'd suggest starting with a simple, low-stakes MCP server. The GitHub example in Microsoft's documentation is perfect for a proof of concept. Get that working end-to-end first, then think about which of your internal systems would benefit most from this kind of integration.

We've been helping organisations across Australia build Copilot extensions and custom agents as part of broader AI strategy work. The MCP plugin approach is one of several options, and the right choice depends on what you're trying to achieve and what infrastructure you already have in place.

If you're building AI agents and want to discuss whether MCP plugins make sense for your use case, reach out. This stuff moves fast, and having someone who's already worked through the gotchas can save you a lot of time.

You can find the full documentation for building MCP plugins in Microsoft's guide at Build plugins from an MCP server for Microsoft 365 Copilot.