Integrating Copilot Studio with MCP servers

Model Context Protocol is an open standard for describing tools an AI agent can call. A server publishes a list of tools with names, descriptions, and input schemas; an agent connects, reads the list, and invokes tools as the conversation requires. Copilot Studio supports connecting agents to MCP servers, which means that instead of describing each API operation to the agent by hand, you point it at a server and inherit everything the server offers. For Dynamics 365 consultants this matters because it changes how integrations reach agents, and because Microsoft and third parties are publishing MCP servers for the systems you already integrate with.

What changes compared with actions

The route described in Copilot Studio agents with external APIs has you defining actions one at a time: an OpenAPI operation or a flow, each with a description you write. With MCP, the server owns the tool definitions. When the server adds a tool or improves a description, every connected agent sees it without a change in Copilot Studio. Tools also carry richer semantics than a REST operation: a server can expose resources (documents or records the agent can read) and prompts (canned instructions) alongside tools.

Practically, an MCP connection in Copilot Studio appears as a set of actions the orchestrator can choose from, subject to the same DLP and connection governance as any other action. The agent does not become smarter; it becomes better informed about what it can do.

Where MCP servers come from

Microsoft's own. Dataverse has an MCP server that exposes its tables and operations, and further first-party servers for Dynamics 365 workloads are appearing. For an agent that needs to read and write Dataverse records, the Dataverse MCP server is the most direct route, with tool definitions maintained by the platform.

Vendors. SaaS vendors are shipping MCP servers as a standard part of their developer offering. If the agent needs to talk to a help desk, a document store, or a data platform that publishes one, use it rather than describing the same API again.

Your own. A server you build, typically as an Azure Function or a container app, exposing your organisation's specific operations: "look up a customer's open orders across Business Central and Dataverse", "check stock at the nearest warehouse". This is where MCP earns its keep, because the tool can encapsulate the cross-system logic and the agent sees one clean operation.

Building a server for Dynamics 365 data

Write tools around business operations, not tables. A tool called "get customer summary" that returns account, open cases, open invoices, and last order, drawing on Dataverse and Business Central behind the scenes, is far more useful to an agent than four tools that each return raw rows. The agent will otherwise chain calls, make mistakes in the joins, and produce slow conversations.

Keep the tool count small and the descriptions precise. An agent choosing among fifty tools with overlapping descriptions picks the wrong one; an agent with eight well-named tools does not. Make tools read-only unless a write is genuinely required, and put any write behind a parameter that makes the intent explicit, so a confirmation step in the agent's topic can gate it.

Host it where the organisation already runs APIs. Put API Management in front if there are other consumers, and log every call with the user identity and the tool name, because agent behaviour is otherwise hard to audit.

Authentication

An MCP server is an HTTP endpoint and the connection to it is a Power Platform connection, so the standard options apply: no authentication for a public server (rare and usually wrong), an API key, or OAuth 2.0. For a server touching Dynamics 365 data, use OAuth with Entra ID and pass the user's identity through, so the server queries Dataverse or Business Central as the user and the platform's own security applies. A server running as a broad service principal hands every agent user that principal's rights, which is the same mistake as an over-privileged integration user in any other context.

Governance

DLP policies control which MCP connectors an environment may use, and a server not on the allow list will fail to connect. Agree the list with the platform team. Treat a third-party MCP server as a third-party integration: review what its tools do, what data leaves the tenant in each call, and how the vendor handles it. A tool description is a promise, not a contract; test what the tool actually returns.

Version the server. An agent built against tool version one that starts receiving version two's changed schema will behave oddly with no error in Copilot Studio. Keep old tool names stable and add new ones rather than changing existing signatures.

What breaks in practice

Servers that expose every table as a tool, so the agent drowns in options. Descriptions written for developers rather than for the model that reads them. Servers with no timeout, so a slow backend stalls the conversation. Connections created with a personal account that later leaves. Agents given write tools without a confirmation topic.

Stability verdict

MCP support in Copilot Studio is real and usable, and the protocol has broad industry backing, which is a good sign for longevity. It is also young: the authentication story, the governance tooling, and the set of first-party servers are all changing quickly, and something that works this quarter may need adjusting next. Build your own servers thin and expect to revisit them. For scoping the agent itself, read building agents with Copilot Studio; for how Copilot Studio relates to the Copilot agents inside Dynamics 365 apps, see Copilot agents vs Copilot Studio.