Dynamics 365 + MCP Explained: Why Customer Service (and Sales) Agents Need Tool Access

In Customer Engagement ·

MCP Customer Service Dynamics 365 Sales Copilot Studio AI Agents How-to

If you want to use AI agents in Dynamics 365 Customer Service and Sales you need a connector designed for the job. Sure, you can use standard APIs and expose tables and pages so the agent can read the data and answer questions; but, if you want your agent to do actual work for you, you need a tool designed to connect an agent to Dynamics. That is the Model Context Protocol; the USB-C port to connect your agents to Dynamics 365 Sales and Customer Service.

In this post I explain MCP for Dynamics Customer Service and Sales and what you can do with it. If you work with Business Central, you can check my other article: Business Central’s MCP server; here the focus is service and sales tools.

What is a Model Context Protocol in Dynamics 365

An MCP in Dynamics 365 is a bridge between your agent and Dynamics, not just the data in it like leads, opportunities and cases, but the application itself. That means you can build agents that work like your digital assistant. You can ask questions and the agent will find information and perform actions.

The MCP is made of three layers: the server, the tools and the client:

In the context of Dynamics 365 Customer Engagement, the MCP host can be Copilot Studio, but other clients such as ChatGPT or Claude Code can also connect to the same servers.

Tools are what set MCP apart from a retrieval-only agent that answers from contacts, emails, or other documents you attached as knowledge. Those agents can read and summarise; tools also let the model act. With tools, the same model can list cases, draft an email, update a record, or resolve a case under the signed-in user’s Microsoft Entra ID identity and security roles, so Dataverse still governs what that user is allowed to do.

If you are preparing for agent-building exams, check my post about the new Agent Builder certification AB-620, which covers tools, MCP servers, and how to govern agent actions in a business application. For case, queue, and knowledge process depth on the service side, MB-230 is still the exam to map.

What’s included at general availability

The Dynamics 365 CX MCP Server - Service is generally available and connects to your Dynamics environment through the Agent 365 Tooling Gateway. It exposes a large catalogue of service tools. Microsoft’s Customer Service MCP tools overview groups them by how service teams work, and the public tool reference currently lists about a hundred named tools.

The available tools are categorised into capability areas that match familiar areas of Dynamics 365 Customer Engagement:

Representatives and supervisors talk to an agent in natural language, and the agent decides which tool to call so you will not see the individual tools. For example, asking for a brief on the next item in a queue may trigger something like pick_case_from_queue and summarize_case in the background; asking for a customer reply may use knowledge search and draft_email. You might need to reference the tool names when you build your agent, connect several agents together, or debug the agent, but not when you use it day to day.

What you can build with Customer Service MCP tools

MCP turns your agent or agents into digital workers that perform actions following instructions in natural language. Here are some examples of what you can build:

Scenario 1: Queue-aware case brief

The agent picks or lists work from a queue, summarises the case, pulls customer context and recent activities, and hands the representative a short brief before they open the form. The user still owns the decision on the call or the chat; the agent removes the first few minutes of hunting across records.

Scenario 2: Draft email with knowledge, human send

The agent finds matching knowledge articles and drafts a customer reply, and can rewrite tone or language if needed. Most organisations do not let the agent send the email on its own. The representative reviews the draft, then either allows the send tool or sends from the case themselves. That keeps brand and accuracy under human review while cutting time.

Scenario 3: Knowledge gap after resolution

After a case is resolved in a way that did not match existing articles, the agent can check for a knowledge gap and draft a new article from the case notes. Publishing stays with whoever owns knowledge governance. The agent proposes content; it does not become the owner of the knowledge base.

Scenario 4: Supervisor SLA stand-up

A supervisor agent lists escalated or at-risk cases by SLA status, summarises a handful of high-priority items, and prepares a short stand-up note for the team. The supervisor still reassigns work and talks to people; the agent prepares the pack so the meeting starts with facts.

As you can see, none of the scenarios above replaces or eliminates solid processes and governance. If case routing is messy and knowledge articles are obsolete, an agent with tools will simply run that mess faster.

Sales vs Customer Service MCP servers

Dynamics 365 Customer Service and Sales share the same protocol, but each product ships its own MCP server with its own tools. The Customer Service server is the one for cases, knowledge, service email, and queue work. The Sales server is the one for leads, opportunities, account research, outreach drafts, and sales catch-up summaries.

There is also a dedicated MCP for Dataverse. If you need plain create, read, update, and delete actions on Dataverse tables for custom tables, or for tables that neither product server covers with a dedicated tool, you can use the Dataverse MCP server as well.

Combining a Customer Service or Sales MCP server with the Dataverse MCP server works when a custom agent has to research an opportunity with Sales tools and then update a custom field that only exists as a normal Dataverse record update.

Sales MCP tools address business areas covered by the application: qualification research and assessments, opportunity health and insights, and Copilot-in-Sales style summaries and drafts. In practice that means things like lead and account research, outreach email drafts, opportunity risks, and record catch-up. Microsoft lists the tools in the Sales MCP overview.

Some of those Sales tools consume Copilot Studio credits, based on the agent feature each tool uses (for example text and generative AI tools, or generative answers). Microsoft maps each Sales MCP tool to a credit type in that overview, and the Dynamics 365 licensing guide has the MCP-specific licence notes, including cases where certain Dynamics 365 Sales licences do not charge Copilot credits for MCP. You do not need the full table memorised to start, but you should know that a sales research agent is not free by default just because MCP is switched on.

How to connect an agent to the Customer Service MCP Server

Copilot Studio

If you build the agent in Copilot Studio, connecting the Customer Service MCP server is mostly identity work, then a short configuration on the agent.

Microsoft separates configuration from day-to-day use. You need System Administrator or Omnichannel Administrator to configure the MCP server, and Customer Service Representative or CSR Manager to run its tools.

You also need a tenant admin to grant consent for the Agent 365 Tooling Gateway app. Then you register a single-tenant Microsoft Entra application for Copilot Studio with permission to that gateway, create a client secret, and use those values when you add the MCP server to your agent. The server URL is the production gateway host plus your Dataverse environment ID. When Copilot Studio shows the sign-in callback URL, you add it as a redirect URI on the Entra app you just created.

On the agent, you create a connection with a user who has Customer Service Representative or CSR Manager, add the tool, and publish. If your representatives will use the agent inside Customer Service, you can also connect the Dynamics 365 Customer Service channel. Microsoft walks through the Entra screens and field names in Connect Dynamics 365 CX MCP Server - Service; the sequence above is enough for you to plan who does what in your tenant.

One detail that is easy to overlook is the server description. Copilot Studio uses that text to decide when to call this server. Write a description that names the work: list, read, and update cases; search knowledge; view activity timelines; draft emails. If the description is vague, the model has to guess.

Other MCP clients

Copilot Studio is the natural host if you already build agents for Customer Service there, but it is not the only option. MCP is a standard, so any client that supports HTTP MCP connections can call the same Customer Service server.

If you use Visual Studio Code, GitHub Copilot CLI, Cursor, ChatGPT, or Claude Code, you typically only need the server URL and a sign-in. Those clients read the sign-in details from the gateway, so you do not paste every authentication URL by hand. That path is useful when you want to test tools while you build, or when your team prefers to host the agent outside Copilot Studio.

A typical VS Code entry looks like this, with your environment ID in place of the placeholder:

{
  "servers": {
    "d365-customer-service": {
      "type": "http",
      "url": "https://agent365.svc.cloud.microsoft/mcp/environments/<environment-id>/servers/mcp_D365CX_Service"
    }
  }
}

Use the production gateway host for production environments. If your environment sits on Microsoft’s test or pre-production Agent 365 gateway, use that host instead; mixing environment ID and host returns an error. Before you open connections widely, your tenant admin should also review Microsoft’s notice about data leaving Dynamics: queries and other data sent through the agent can be processed by the client or service you connect, under that service’s terms.

Governance decisions

The technical connection is only half of the work. You still have to decide what the agent is allowed to do, and for which people.

Most teams start in a sandbox with a small pilot group, often one queue or one product line. You keep configuration with System Administrator or Omnichannel Administrator, and you let CSR or CSR Manager accounts run the tools so the audit trail matches how you already secure Customer Service. On the first pass it is usually enough to allow read, summarise, and draft. Resolve, send, reassign, and publish can wait until your team has a clear way to correct a bad close, a bad email, or a bad knowledge draft.

The same foundations that make human service work well still apply when agents use MCP. Agents that pick work from queues depend on coherent queue design; agents that flag SLA risk depend on working SLAs and timers; and agents that draft from knowledge depend on articles people trust. The pattern is the same on the ERP side with Business Central MCP: tool access without process discipline creates more problems than it solves.

What to do next

A practical way to get started is to follow Microsoft’s connection steps for a non-production environment and test an agent there: connect a Copilot Studio agent or another MCP client in a sandbox, sign in with a CSR test account, and try one narrow job end to end, for example a queue brief or an email draft that a person still sends. Note where the agent is wrong before you widen the tool set. If sales is in scope for you, connect the Sales MCP server the same way.

MCP is valuable when the process is ready for an agent to touch it. Give the agent the tools for one clear job, keep identity and roles aligned with how you already secure Customer Service, and expand when your team can explain and reverse what the agent did.