What it does

The Customer Insights MCP server exposes Customer Insights - Data and Customer Insights - Journeys as callable tools for agents and LLM clients. There is one server for both apps, so an agent in either can call any tool. It's built on the Dataverse custom API pattern (a list-tools API and a call-tool API), and the server definition ships in the base solution (CxpClient) with each app adding its tool providers as extensions.

Key facts

• Thirteen tools. Twelve are read-only: find_customer, get_customer_by_source_id, get_customer_by_contact, get_customer_details, get_customer_segments, get_customer_measures, get_customer_predictions, get_cluster_information, list_data_sources, check_consent, get_unsubscribe_link and validate_email.
• create_journey is the only writer. It validates the payload, enriches it, validates again, then creates the journey record. It isn't idempotent, so a retry after a failure can create a duplicate.
• The usual pattern is two steps: resolve a unified customer ID (by name, Dataverse contact GUID or source-system record ID), then call the detail tools. get_customer_details gives the whole Customer 360 in one call, including source records with a flag showing which source supplied each winning unified value.
• list_data_sources returns source entities, record counts, whether each source's columns appear in the unified profile, and flags sources whose fields didn't resolve. Call it before get_customer_by_source_id to get valid entity names.
• Profile tools read from Dataverse virtual entities, so you see live unified data. find_customer lists profiles instead of searching if you give it no name, and pages with top and hasMore.
• check_consent and get_unsubscribe_link call the msdynmkt_checkconsent and msdynmkt_getunsubscribelink custom APIs, the same consent service Journeys uses at send time, so the agent's answer matches what a journey would do. They work in environments with only Shared Consent deployed, such as Dynamics 365 Sales.
• Security is layered: mTLS, custom API privileges, tool-level privilege checks and row-level security. Authorisation runs as the calling user and the server doesn't escalate privileges.

When to use / skip

Use it when an agent needs to answer "who is this customer and may I contact them" from governed data rather than from a bespoke API wrapper. It's a good fit for service and sales agents, and for outreach agents that must check consent first. Skip it for bulk work: Learn warns that calls through MCP can be slower than direct service calls, so don't build high-throughput processing on it.

Configuration decisions

• Which identity the agent runs as, and what Dataverse security role that identity holds. Tools only see what the caller can see.
• Whether agents get create_journey at all, given it's the single write path. Splitting read-only and write agents is sensible.
• For consent tools: at least one compliance profile with purposes and topics. The default profile has a Commercial purpose (restrictive) and a Transactional purpose (nonrestrictive).
• How agents are told to confirm the outcome before retrying create_journey.
• How you connect the server to clients; see the gateway doc.

Gotchas

• Missing tools in an agent usually mean the user lacks privileges on the underlying Dataverse tables, not that the server is misconfigured.
• Consent coverage is narrow: you can check consent and generate unsubscribe links, but you can't update consent, manage purposes and topics, or retrieve consent model metadata over MCP.
• All tools share one server-level scope definition, so per-tool control comes from tool-level authorisation, not separate scopes.
• A retried create_journey creates a second journey. Nothing deduplicates it for you.
• Unsubscribe links are unique per contact point and message context, which is good for audit but means you can't generate one and reuse it across messages.

Consultant notes

• Make the agent run check_consent immediately before sending, with the real purpose, topic, channel and business unit. A stale or guessed purpose ID gives you a confident wrong answer.
• Test with a low-privilege user as well as an admin. The first demo always works as System Administrator and then production finds the missing privileges.
• Treat validate_email as a pre-flight check in any journey-building agent; unresolved placeholders are cheaper to catch there.
• Agree the write policy for create_journey early. It's the tool a client will want to switch off the day an agent loops.

---

Worth rechecking when new tools appear on the reference page, especially anything that writes data or widens the consent tools.