Dataverse Meets Claude, Cursor and Copilot via MCP

The Dataverse MCP integration reached a milestone on July 6, 2026: Microsoft's Dataverse coding-agent plugin, previously usable in Claude and GitHub Copilot, can now also drive Cursor. It is a small headline with a large subtext — the same plugin that lets a coding agent read and write your Dynamics 365 and Power Platform data does so through a fixed set of named, individually auditable tools, not open database access.

Most coverage will compress this into “Dataverse expands to Claude, Cursor and Copilot” as if all three landed at once. They didn't. Claude (via the Claude Marketplace) and GitHub Copilot got the plugin on April 30, 2026; only Cursor is new on July 6, alongside a broader push into MCP certification and a catalog of ready-made servers. Getting that timeline right matters, because the governance story underneath is the part an agency actually has to defend to a client.

This guide separates the real news from the rewrite. It maps the router architecture, lays out the full 15-tool inventory in one table, and explains what “respects existing RBAC” mechanically means — per-user security inheritance and explicit human approval on destructive writes — as described by Microsoft in its own posts. Every figure below is sourced to Microsoft's Power Platform announcements and the open-source repository that ships the plugin.

The July 6, 2026 Power Platform Blog post — “Dataverse Is Your Agent Data Platform: Here's What's New in July 2026”, by Julie Koesmarno, Principal Group Product Manager for Microsoft Dataverse — states the plugin is now available for Claude, Cursor and GitHub Copilot. Read on its own, that line invites the misread that all three are brand new. They aren't.

Claude and GitHub Copilot support shipped more than two months earlier, on April 30, 2026, in a separate developer-blog post (“Dataverse Plugin Is Now on the Claude Marketplace”, by Suyash Kshirsagar). The net-new surface on July 6 is Cursor — plus an MCP certification programme and a catalog of ready-made servers. And the repository README lists a fourth coding agent, Codex, beyond the three Microsoft names in its headline, so the plugin's real reach is at least four surfaces.

The plugin does not add a new way to reach Dataverse. It is a router built on an open-source skill architecture (MIT-licensed, hosted at github.com/microsoft/dataverse-skills) that reads a natural-language request and dispatches it to whichever of four existing tools is best-suited: the Dataverse MCP server, the Python SDK, the PAC CLI, or the Dataverse CLI. Conversational queries lean on the MCP server; bulk operations go to the Python SDK; schema work routes to the Web API and CLIs.

That design choice is why the governance conversation is even tractable. Because every path already existed and already enforced its own permissions, the plugin doesn't create a new bypass — it standardises how an agent picks among them. The setup work is handled by the agent; the security approvals stay where they were. If you want the mechanics of the layer it routes into, our walkthrough on how to build an MCP server from scratch covers the protocol end to end.

The repository ships eight specialist skills, each scoped to a slice of the platform. One of them, dv-overview, is the request router that decides which specialist handles a given ask. The rest cover connection, querying, data changes, metadata, solution lifecycle, administration, and security. Splitting the work this way is what makes the capabilities auditable: a security-conscious team can reason about each skill's scope rather than one opaque “Dataverse access.”

Underneath the plugin sits the Dataverse MCP server, documented separately in Microsoft's June 8, 2026 post “Dataverse MCP Server: Understanding the New Tool Shape” by Kent Weare. It exposes 15 named tools across five groups. The table below pulls them into a single view with the two facts a security reviewer cares about most: whether each tool reads or writes, and which ones the source says require explicit human approval. The read-or-write column is our own classification derived from each tool's stated function; the approval column is taken verbatim from Microsoft's tool descriptions.

Tally the classification and the shape is clear: of the 15 tools, five are read-only (search_data, read_query, search, describe, file_download) and ten can write. Only two — delete_record and delete_table — carry an explicit approval gate in their own descriptions. That is a deliberate asymmetry: the source reserves mandatory human sign-off for the two irreversible destructive operations, while trusting create and update paths to the user’s existing permissions.

Microsoft's July 6 framing says the plugin enforces least-privilege security, follows documented auth patterns, and respects existing Dataverse RBAC. Repeated as a marketing line, that says little. The June 8 “tool shape” post gives it a mechanism: the server is designed to validate that users only access data they are already permitted to see. In practice that means the agent runs under the calling user's existing Dataverse security role — it does not receive a separate, elevated identity. A consultant with read-only access to a table gets a read-only agent against that table. For the general version of this idea, our guide to RBAC design patterns for agentic AI covers the same least-privilege principle across any stack.

One honest caveat for anyone recommending this to a client: these are Microsoft-stated design intentions, not the findings of an independent security audit. No third-party penetration test or audit of the Dataverse plugin specifically surfaced in our research. The architecture is sound on paper — named tools, per-user context, approval gates on deletes — but “the vendor says so” is the correct frame until an external review exists.

Beyond per-user roles, Microsoft documents administrator-side controls that gate the plugin before any single request is made. Together they describe defence in depth: consent at the tenant, an allowlist at the environment, and credential handling at the device.

The MCP endpoint itself lives at /api/mcp on the target environment, reached over a stdio transport through an npm proxy. None of these controls is exotic; the point is that they are the same controls Dataverse administrators already operate, now applied to an agent surface rather than a human one. For a team that already runs Power Platform governance, the mental model transfers cleanly — and the checklist in our MCP server security best practices guide is a useful companion when you harden your own surface.

The Dataverse plugin arrives inside a wider Microsoft MCP move. The July 6 post cites a catalog of 60-plus ready-made MCP servers — a figure worth reading carefully. It is Microsoft's own stated aggregate spanning several products (Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry, and GitHub Copilot), not an independently tallied or Dataverse-specific number. Treat it as a vendor-stated catalog count, not a verified market statistic.

The more consequential piece for partners is an MCP certification programme for ISVs. It is a three-step path: prepare a certification package with the MCP manifest and endpoint URL, a Tools JSON file, and Key Vault-backed auth details; select the “Apps and Agents for M365 and Copilot” offer type and submit via Partner Center; and, once certified, the MCP becomes available for customer adoption across Copilot Studio and Azure AI Foundry. Microsoft also supports a “bring your own MCP” path for connecting custom tools and internal workflows under enterprise governance controls.

All of this lands on ground that was already MCP-native. The protocol's connector ecosystem has been growing fast — third-party registry trackers counted on the order of 10,000 MCP servers by April 2026, up from roughly 6,800 at the end of 2025 (an increase of about 47% in four months), and every major coding host, from Claude Code and Cursor to VS Code's Copilot, shipped MCP support during 2025. The Dataverse news is Microsoft shipping an application on top of that existing layer, not the layer itself arriving. Our deeper look at how fast MCP adoption is moving puts these figures in fuller context.

For an agency that builds custom, agentic systems for clients, this release is useful less as a product to adopt and more as a reference architecture to point at. When a client asks whether it is safe to let an AI coding agent touch their CRM data, “named tools, per-user roles, approval gates on destructive writes” is a concrete, defensible answer — and now there is a shipped Microsoft example that embodies it. That is worth more in a governance conversation than any abstraction.

Looking forward, the pattern here — a fixed, named tool surface with per-user identity and human gates on the dangerous operations — is likely to become the default shape for how enterprise platforms expose themselves to agents. The specific artifact that matters isn't Cursor support; it is that a major vendor has now shipped “governed agent access to enterprise data” as a concrete product rather than a whitepaper. Agencies that internalise the pattern will be able to answer the safety question long before the next platform ships its own version. If you're scoping this kind of governed agent access into a client's CRM automation build, that mechanism-first framing is exactly where the conversation should start.