A solution architect on a recent Dynamics 365 Sales engagement did what the documentation told him to do: he pointed a GitHub Copilot session in VS Code at the newly GA’d Dynamics 365 Sales MCP server, asked it to pull up a stalled opportunity, and watched it come back with a clean summary and a suggested outreach email. Then he asked it to update the opportunity’s close date. Nothing happened. No error, no record change, just a polite explanation that the tool wasn’t available. He had connected the right server. He just hadn’t connected both of them.
That gap trips up more than one team standing up agent access to Dynamics 365 Sales for the first time, because the Dynamics 365 Sales MCP server, which reached general availability in February 2026 after a preview that started in mid-2025, was never designed to be the only door into the system. It is a purpose-built layer that exposes a narrow set of sales-specific actions: retrieving a lead summary, qualifying a lead into an opportunity, generating an outreach email, listing leads assigned to a seller. Anything that looks like ordinary create, read, update, or delete work against Dataverse records sits behind a separate, general-purpose Dataverse MCP server. Architecting AI access to Sales properly means treating these as two components of one system, not as interchangeable options.
What the Dynamics 365 Sales MCP server actually exposes
The Sales MCP server groups its tools into three functional clusters that mirror existing Copilot experiences inside the app: Sales Qualification Agent tools, Sales Opportunity Agent tools, and the broader Copilot in Sales tool set. In practice this means an MCP client authenticated against this server can list a seller’s leads, pull a structured summary of a specific lead or opportunity, move a qualified lead into an opportunity record, and draft or send an outreach email using the same generative logic that powers Copilot inside the Sales workspace. These are opinionated, workflow-shaped actions. They encode the same business rules a seller would hit clicking through the UI, which is exactly the point: an external agent gets sales-process guardrails for free instead of raw table access.
What it deliberately does not expose is a general write path. There is no “update any field on any opportunity” tool here, and that is not an oversight so much as a design choice that keeps the blast radius of an agent request contained to well-understood sales actions.
Where Dataverse MCP fills the gap
For anything outside that workflow shape, whether it’s a custom Power Apps process reading a related quote table or an agent that needs to write directly to a Dataverse entity, the connection point is the separate Dataverse MCP server, reachable at https://<OrgURL>/api/mcp. It exposes four core operations: read_query, create_record, update_record, and describe, the last of which lets a client inspect table and column schema before it attempts a write, which matters a great deal in a Dataverse environment where customizations can mean the “standard” schema an agent expects has drifted from what is actually deployed.
One detail worth building into any design review: the Dataverse MCP server is enabled by default for Microsoft Copilot Studio but disabled by default for every other client. If a team is connecting GitHub Copilot, a custom agent, or any third-party MCP-compliant tool, an admin has to go into the Power Platform admin center, open the target environment’s Settings, navigate to Product > Features, and turn on “Allow MCP clients to interact with Dataverse MCP server,” then explicitly allow-list each client under Advanced Settings. Nothing connects by accident, which is a reasonable default for a capability that can write to production data, but it also means a “why isn’t this working” support call is often really a “did anyone flip this switch” question.
Configuring both servers side by side
For a VS Code or other mcp.json-driven client, the practical setup is two separate server entries pointed at two different endpoints rather than a single unified connection string. The Sales server entry targets the Agent 365 service path scoped to the environment and the Sales MCP server registration, something like https://agent365.svc.cloud.microsoft/mcp/environments/<EnvironmentID>/servers/msdyn_SalesMCPServer, while the Dataverse entry targets the organization’s own API surface directly. Both are declared as HTTP-type MCP servers. Getting an agent to feel like it has coherent access to “Dynamics 365 Sales” as a single system is really a matter of configuring both endpoints correctly and letting the client route each request to the appropriate one, which most MCP-aware clients handle transparently once both connections are live.
It’s worth noting explicitly for architects scoping this work that Claude Desktop is not on Microsoft’s list of supported clients for the Sales MCP server as of this writing; Copilot Studio, GitHub Copilot in VS Code, and other MCP-compliant clients are. That’s a constraint worth confirming before a client commitment gets made in a statement of work.
Security enforcement isn’t a separate layer, it’s the same one
The question every security-conscious stakeholder asks first is whether an AI agent connected through MCP can see or touch more than the person who authorized it could. Microsoft’s own documentation is direct on this point: the Dataverse MCP server respects existing Dataverse security roles and row-level security, meaning a connected agent can only access the tables and records that the authenticated user’s security role already permits. There is no parallel permission model to reason about, no separate access control list to maintain for agent traffic. The security model an organization has already built for its human users through business unit hierarchies, field-level security, and role-based table access extends automatically to MCP-connected agents acting on that user’s behalf. That’s a meaningfully simpler governance story than a lot of teams expect walking into this, and it’s worth stating plainly to a CISO who assumes agent access requires a whole new access-control project.
What isn’t yet documented in detail is rate limiting or granular audit logging specific to MCP calls, and that’s a fair gap to flag rather than paper over. Teams putting this into production should validate logging behavior in their own tenant and treat detailed throttling behavior as something to test empirically rather than something to design around from a published number that doesn’t exist yet.
The licensing detail that changes the cost conversation
Since December 15, 2025, Dataverse MCP tool calls made by AI agents built outside Microsoft Copilot Studio are billed against Copilot credits, unless the organization already holds qualifying Dynamics 365 Premium licensing or a Microsoft 365 Copilot User Subscription License, in which case that usage is included. Agents built inside Copilot Studio are exempt from this particular charge model. The Sales MCP server has its own credit consumption structure layered on top, with different tool categories, such as basic text and generative AI tools versus generative answer tools, billed at different Copilot Studio credit rates. For an architecture that mixes a Copilot Studio-native agent with a custom VS Code-based developer tool hitting the same environment, that means two different cost models are running in parallel, and a licensing conversation that used to be a single line item now needs to account for which client is making which call.
What to check before this goes into a proposal
Confirm which specific tools a client actually needs before assuming both servers are required. A workflow that only needs lead qualification and outreach drafting may never need Dataverse MCP write access at all, which simplifies both the security review and the licensing conversation considerably. Where write access genuinely is required, treat the admin center toggle and client allow-listing as a discrete deployment step with its own change ticket, not an assumed side effect of installing an MCP client. And build the Copilot credit cost of both servers into a pilot’s budget from day one, since credit consumption for generative tools scales with usage in a way that a fixed per-seat license does not.
Teams at Routeget Technologies have walked several clients through exactly this two-server design decision over the past few months, mostly because the documentation, while accurate, spreads the full picture across three or four separate Learn pages that don’t obviously reference each other. Getting the architecture right the first time saves a rework cycle that otherwise shows up a few weeks into a pilot, right around the point someone asks the agent to actually change a record instead of just describing one.
#DynamicsSalesMCP #DataverseMCP #AIinCRM #CopilotStudio #EnterpriseAI #D365SalesArchitecture