This matters because MCP already gives makers and developers a consistent way to connect agents to real business data without every client needing a custom Dataverse integration. Our enhancements ensure the Dataverse MCP experience is easier to reason about through a clearer tool shape. Agent surfaces like Copilot Studio, GitHub Copilot in VS Code, GitHub Copilot CLI, Claude Desktop, Claude Code, and other MCP-compatible clients can now connect to the Dataverse MCP endpoint and experience this new tool shape.

What changed

The important change is not that Dataverse supports MCP. It already does. The change is that the experience is now easier to understand through a concrete set of tools. Instead of thinking about MCP as a generic connection, we can now talk about the actual tools an agent can use. The Dataverse MCP server exposes tools for common data and metadata tasks, including:

This tool shape is important because it defines the contract between the agent and Dataverse. The agent is not just connected to Dataverse in a broad sense. It has a set of named capabilities that can be reasoned about, allowed, blocked, audited, and improved over time.

For additional information, please see the documentation for full list of Dataverse MCP tools and billing rates.

Why the tool shape matters

For users, makers, and pro developers, the MCP tool shape creates a cleaner mental model.

If an agent needs to:

• Understand the data model, it can use tools such as search, describe, and schema-related responses.
• Answer a question from data, it can use read_query or search_data depending on whether the scenario is structured query or broader search.
• Create or update business data, it can use create_record, update_record, or delete_record with the right approvals and safeguards.
• Help scaffold or evolve a simple schema, it can use table tools such as create_table, update_table, and delete_table.
• Move files in or out of Dataverse, it can use init_file_upload, commit_file_upload, and file_download.

That means agent experiences can move from “tell me how to do this” to “help me inspect, reason, and act against my environment,” while still going through explicit tool boundaries.

A practical example

Imagine a user asks: Which accounts have open follow-up items, and can you create a task for the ones missing an owner?

With the MCP server connected, the agent can use the Dataverse tools to inspect the relevant tables, query the data, and create records where appropriate. The interaction becomes more grounded because the agent can work with the actual Dataverse environment instead of relying only on user-provided context.

Governance still matters

The MCP server does not remove the need for governance. In fact, the tool shape makes governance more visible.

Administrators have control over which clients have access to to the environment via MCP server. This ensures that only approved agent surfaces are accessing business data. Additional capabilities such as ‘allowed tools’ and strong role based access control ensure users only have access to data that their security context allows.

The practical guidance is:

1. Enable MCP only for environments where agent access makes sense.
2. Allow only approved clients.
3. Understand which tools are exposed.
4. Treat write-capable tools differently from read-only tools.
5. Validate that users only access data they are already permitted to see.

Summary

The most interesting part of this Dataverse MCP server enhancement is the move toward a clearer, more concrete tool shape.

The updated tool shape makes Dataverse more agent-ready. It gives agents a standard way to discover tables, inspect schema, query data, and use controlled Dataverse tools. For makers, this means more natural AI-assisted workflows. For developers, it means a cleaner integration pattern. For admins, it creates a more explicit surface to govern.

MCP turns Dataverse into something agents can use directly, but the tool shape determines how safe, useful, and predictable that experience becomes.

Additional resources

• Connect to Dataverse with Model Context Protocol
• Configure the Dataverse MCP server for an environment

The post Dataverse MCP Server: Understanding the New Tool Shape appeared first on Microsoft Power Platform Blog.

Companion post to our Build 2026 session: Microsoft Dataverse plugin: unleashing coding agents on the enterprise

Coding agents are powerful, but without domain tooling they hallucinate and produce broken solutions. The Dataverse plugin for coding agentssolves this by giving AI agents guardrailed access to tables, columns, relationships, views, security, and solutions.

In our Build 2026 session, we showed how a natural-language request triggers multi-step provisioning, data imports, and validation. This is all executed autonomously, through the plugin’s tool integration and patterns that make agent-driven Dataverse development reliable at scale.

To bring this to life, we built a series around Zava Coffee Co., a growing B2B roaster and distributor running on spreadsheets, email, and copy-paste. When it came time to modernize, they didn’t need a massive team and spend weeks in the the various portals. Instead, they installed the Dataverse plugin and described what they needed, in plain English, from a GitHub Copilot terminal.

This post, and accompanying video, walks through the three scenarios:

1. Maya, a developer building her first data model, app form and view
2. Riya, a Revenue Ops analyst running her CRM in natural language
3. Amara, a platform admin locking down security across two regions.

Scenario 1: Zero to App in One Session

Persona: Maya, Developer, new to Dataverse
Goal: Turn four operational spreadsheets into a working Dataverse application with schemas, relationships, and real data.

Maya had never touched Dataverse. She didn’t know her org URL, didn’t know what a publisher prefix was, and shouldn’t have to. She installed the plugin, typed one sentence “Connect me to my Dataverse environment” and the agent discovered her environments from her Microsoft identity, configured everything, and verified the connection.

Then she describes her roast batch tracking system in business terms: beans, batches, quality checks, orders, and the relationships between them. One prompt produced four tables with choice columns, lookups, a self-referential parent-batch relationship for re-roasts, a many-to-many between batches and orders, a main form, and a filtered view — all packaged in a solution.

The data import is where it gets real. Maya pointed the agent at the team’s four Excel files. No GUIDs anywhere, just business keys for a bean variety and batch numbers. The agent figured out dependency order, loaded parent tables first, resolved the self-referential re-roast links, split a comma-separated batch list into proper many-to-many associations, and left an unlinked order alone instead of erroring out. That’s a data pipeline, not a sample generator.

What the plugin solved: Maya went from zero Dataverse knowledge to a connected, working application that included schemas, relationships, forms, views, and three years of real operational history, all without opening the maker portal, reading a setup guide, or writing a single line of FetchXML.

Scenario 2: Talk to Your CRM in Plain English

Persona: Riya, RevOps Analyst
Goal: Run Friday pipeline prep in five minutes instead of forty-five minutes, no Advanced Find, no Excel pivots, no chasing teammates in Teams.

Riya already lives in a terminal. Every Thursday she preps Carlos’s sales pipeline review by pulling open deals, flag at-risk cafés, makes sure last week’s calls are logged. Today that’s forty-five minutes of Advanced Find queries, Excel exports, and detective work.

With the Dataverse plugin, she asked: “Show me Carlos’s open opportunities over $100K closing this quarter.” The agent looked up Carlos by name in the systemuser table, translated “this quarter” into a date range, and returned café names, deal names, dollars, and stages — no GUIDs, no statecode = 0, no estimatedclosedate syntax.

Then she asked for “cafés in Portland that haven’t reordered in 30 days.” That’s not a field, it’s a relationship plus date math. The agent joined accounts to closed-won opportunities, computed the gap, and handed Riya a clean call list.

The trust moment: When Riya said “Add a note to the Portland cafe opportunity,” the agent found the open deal on that account. She also logged a phone call on behalf of Carlos, the agent set the owner to Carlos (his call), marked it completed (already happened), resolved the contact as a participant, and linked it to the right account, all inferred from one sentence.

What the plugin solved: Riya collapsed 45 minutes of Advanced Find, Excel pivots, and manual activity logging into five minutes of conversational CRM access. Carlos got a cleaner pipeline review without doing anything differently.

Scenario 3: Manage Your Environment Like a Pro

Persona: Amara, Platform Admin
Goal: Draw security boundaries for two regions and three job functions, validate every line, and package it in a deployable solution.

Zava doubled in size and opened a Seattle hub. Amara’s problem: warehouse staff can see deal sizes, sales reps can see quality scores, and anyone can read customer lifetime value. She needed to draw lines and she wanted to describe the security model once, not click through six sections of the admin portal.

She connected with an admin posture: “Verify I have System Administrator privileges before we start.” The agent confirmed her role before offering to do anything destructive. Then she described the full security plan in one prompt: two business units (Portland, Seattle), three custom roles scoped appropriately, field-level security on the sensitive lifetime_value column, an access team template for cross-region collaboration, and three user assignments, all in a ZavaSecurity solution.

The invisible prerequisites: The agent enabled the column for field-level security at the schema level before creating the Field Level Security (FLS) profile. This step, when missed, produces no error and no audit entries. It assigned the profile to roles, because a created-but-unassigned profile does nothing. It added every security component to the solution explicitly, since roles and FLS profiles don’t auto-add.

Validation by impersonation: Amara asked the agent to simulate each user’s access. The result was a clear pass/fail table — Diego can read accounts but not lifetime_value (FLS), Marcus can read roast batches but not accounts (role), nobody can see across business units. Red Xs and Green checkmarks in all the right places, with the why annotated next to each cell. That’s the admin equivalent of a unit test. Allconfiguration confirmed in seconds, not browser-tab-per-user.

She then shared one record cross-region via the access team template. This was one sentence, no GUIDs and enabled three-layer column auditing (org, table, column) so future reads are logged.

What the plugin solved: In one session, Amara stood up two BUs, three roles, FLS with proper assignments, a team template, three user assignments, validated by impersonation, configured a cross-region share, and turned on auditing. Every component lives in a solution she can version and redeploy across environments.

Three Users, Three Jobs, One Unified Approach

The common thread across all three scenarios is : describe your intent in plain language, the agent translates it into the right combination of Dataverse operations. Maya never learned what a publisher prefix is. Riya never wrote FetchXML. Amara never opened the BU management UI. Each person brought a different problem and a different level of platform expertise and the same plugin met all three where they were.

The Dataverse Skills pluginis available now on the Claude and GitHub Copilot marketplaces. Install it, connect, and start building.

👉 Watch the full Build 2026 session:  Microsoft Dataverse plugin: unleashing coding agents on the enterprise 

Learn more about what’s new in Dataverse: aka.ms/DataverseMay2026

The post Microsoft Dataverse Plugin: Unleashing Coding Agents on the Enterprise – Microsoft Build 2026 appeared first on Microsoft Power Platform Blog.