Microsoft Copilot with Model Context Protocol

September 8, 2025

Microsoft Copilot refers to a multitude of AI experiences in M365 and Bing. The M365 Copilot versions are available as a free Copilot Chat version and a paid Copilot version. The latter allows for configuring agents which can consume Graph connected knowledge, as well as to use skills, tools and thus the Model Context Protocol (MCP).

Within Copilot Studio, you can configure an agent to your needs. This is a democratic process, similar to the OOTB Teams governance: everyone can create its own agents and share these. Here, skill and tool integrations generally leverage PowerAutomate connectors and thus allow for accomplishing even tasks on premises (see also our blog post on Jira on-premises integrations) and are created also by individual users within their PowerAutomate subscriptions.

Copilot Integration of the RheinInsights Retrieval Suite

What is MCP in Copilot Good for?

Among the broad range of integrations now also come those via MCP. The advantage of these MCP server integrations is that these can provide general service descriptions rather than rigid API contracts. As an AI to AI communication protocol, MCP is intended for very loose integrations (one might say, similar to human to human communication). This means once Copilot detects the intent of an interaction, it decides on going for a discussion with an MCP server. The receiving MCP server then takes over decision making for the given input, takes an action or delivers a result or might even talk itself to another MCP server.

How Easy Is an MCP Integration in Copilot?

The integration of MCP in Copilot actually is quite straight forward. Remote MCP servers are configured via PowerAutomate custom connectors and here via YAML. And Server-to-Server authentication is also supported by the protocol and by PowerAutomate. Thus, once a custom connector is defined, it can be used in a multitude of agents. It only needs to be connected in each agent’s settings.

From a governance perspective, such custom connectors have one owner who is the user who defined the connector. The connector also lives in this user’s subscription. Thus, you need to make sure that if such an owner leaves the organization, the connectors are reassigned to new owners or co-owners.

Where Becomes the Integration a Bit Complex?

The YAML file defines which MCP protocol is used. As we write in our previous blog posts, we recommend using Streamable HTTP. Thus the YAML file must contain
x-ms-agentic-protocol: mcp-streamable-1.0

Please note that if you define a wrong protocol here, you might pass the YAML verification (by not testing the endpoint and ignoring it is not working) but you will run into issues once you test your integration in Copilot.

Also custom http headers might pose challenges. If your MCP Server or a proxy server (for instance ngrok) requests additional parameters, in form of mandatory http headers, then you need to decide if a user should interactively provide these parameters in the dialog with Copilot. Or you need to statically define such a parameter in the agent’s settings.

So of course it is important to test your custom connector and Copilot experience before publishing the agent.