Want help applying this guide?Ask the DripTell team
A service agent still opens cases correctly on Monday. On Tuesday, an administrator learns that the D365 Service MCP Server behind it is deprecated. The unsafe response is to treat this as a URL change. The safer answer is to build the new connection beside the old one, prove the permissions and real service actions, move clients deliberately, and remove the deprecated tool last.
Microsoft says the D365 Service MCP Server has been deprecated since November 24, 2025 and will be removed in a future release. It does not give a removal date. Microsoft now directs customers to the new Dynamics 365 Customer Service MCP Server. That means there is time to test, but no sensible reason to keep building on the old path. Microsoft's current deprecation notice is the authority for that product status.
MCP means Model Context Protocol. It lets an AI client discover and call approved tools. A working connection is therefore more than network reachability. It includes identity, permissions, data boundaries, tool discovery, record access and the actions a service representative can perform.
Start with the work the old connection performs
Before configuring anything, write down what depends on the old server. Use real tasks rather than a list of tool names. Can a representative find a case, read its activity history, search knowledge, draft a reply, add a note, reassign work or resolve the case? Which clients call those actions, and which environment does each client use?
This inventory matters because a successful sign in can hide a broken workflow. A client may discover tools but fail when it touches a protected record. It may read a case but lack permission to update it. It may also expose a broader set of actions than the team intended.
Name an owner for every dependency. Include the service process owner, Dynamics administrator, identity administrator, security reviewer and the person responsible for each AI client. If nobody owns an action, do not quietly migrate it.
Build the new path beside the old one
Microsoft documents the new Dynamics 365 CX MCP Server for Service behind Agent 365 Tooling Gateway. The gateway handles authentication to Dataverse, and each environment has its own server URL and connector configuration. Discovery capable clients can read the OAuth metadata automatically. Copilot Studio may require manual OAuth settings. Microsoft's connection guide also says the required administrator consent must exist in advance.
- 1Inventory the workList the cases, knowledge actions and approved updates the old connection performs.
- 2Map the accessMatch each action to the person, role and environment that genuinely needs it.
- 3Connect beside itBuild the new environment specific path without removing the old one.
- 4Prove real casesRun representative read, write, denial and failure tests with accountable users.
- 5Retire with evidenceRemove the old connection only after clients, logs and owners all pass review.
Create the new connection in a test environment first. Do not point every production client at it during the first setup. Record the environment ID, intended client, approved users, required Dataverse roles and the exact business actions in scope. Keep secrets out of tickets and shared documents. If your team needs a general checklist for this part, DripTell's API authentication guide explains the same least privilege habit without claiming that DripTell configures Microsoft products.
Test permissions before workflows
Microsoft lists System Administrator or Omnichannel Administrator for configuration and Customer Service Representative or CSR Manager for use. Those role names are a starting point, not proof that every user should receive broad access. The new server also enforces Dataverse privileges when tools run.
Test with representative accounts. One should have the intended service role. Another should be deliberately restricted. Confirm that the first user can discover and execute only the required actions, while the restricted account receives a safe denial. Repeat this for a normal record, a restricted record and a different environment.
The connection guide warns that linking Dynamics 365 to external services can move data outside a Dynamics boundary. Treat that as an architecture decision. Record which client receives queries or customer data, where it processes them, and which compliance or residency review approved the route. DripTell's security overview and MCP integration page show how we describe our own access boundary; they are not a substitute for Microsoft's tenant review.
Prove real cases before cutover
A useful test set should follow one case from discovery to an approved outcome. Include knowledge retrieval, a record update and a handoff or denial. Also include stale credentials, the wrong environment, missing consent, insufficient privileges and an unavailable gateway. The failure path is part of the product.
| Migration gate | Evidence to keep | Stop if this is missing | Owner |
|---|---|---|---|
| Connection | Successful sign in and tool discovery in the intended environment | Client reaches the wrong environment or cannot refresh access | Identity administrator |
| Read access | Correct case and knowledge records for the test user | Restricted records appear or expected records are hidden | Dynamics administrator |
| Write access | Approved note or status update appears once with the right actor | The update fails, repeats or has unclear authorship | Service process owner |
| Failure control | Denied and unavailable cases produce a safe, visible response | The client retries blindly or hides the failure | AI platform owner |
| Cutover | Every production client has a named result and rollback path | One client or workflow remains untested | Migration lead |
Run the same cases through old and new paths while the old connection still works. Compare results, not just response text. Check the record ID, actor, timestamp, changed fields and audit evidence. DripTell teams use the same principle in our AI agent testing guide: a convincing answer is not proof that the underlying action was safe.
Remove the old connection last
Move clients in small groups. After each group, watch authentication failures, denied tool calls, repeated updates and unresolved customer work. Keep a short rollback window with a named decision owner. Do not leave both connections active indefinitely, because duplicate paths become an access and support problem of their own.
Removal is safe when every client points to the new environment specific server, the required roles pass, restricted roles fail correctly, real workflows complete once, monitoring has an owner and the deprecated registration is no longer needed. Then remove the old tool and document the date, decision and rollback evidence.
For teams also connecting customer messaging and AI workflows outside Dynamics, DripTell publishes its own developer surface and customer service AI controls. Keep those systems separate in the migration record. A Microsoft server replacement should never imply an integration or permission that has not actually been configured.
Frequently Asked Questions
Has Microsoft announced the removal date
No. Microsoft says the old D365 Service MCP Server will be removed in a future release, but the current notice does not give a date. Plan now and avoid inventing a deadline.
Can we replace only the endpoint
Not safely. The new route uses Agent 365 Tooling Gateway, environment specific configuration, OAuth consent and Dataverse permissions. Recheck identity, discovery, access and each important action.
Should every user receive an administrator role
No. Use administrative roles for configuration and the narrowest suitable service roles for use. Verify both successful and denied actions with representative accounts.
What is the final cutover proof
Keep evidence that every client reaches the intended environment, allowed actions complete once, restricted actions fail safely, customer records stay accurate and an accountable owner can see failures.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy