Dataverse MCP Server

---
title: "Dataverse MCP Server: Tool Shape Is Your New Security Perimeter"
description: "Microsoft's Dataverse MCP Server turns your system of record into agent-callable tools. The contract you define, not the platform, decides what an LLM can do."
date: 2026-06-18
tags: ["dataverse", "mcp", "ai-agents", "security", "power-platform"]
image: "/images/blog/diagrams/dataverse-mcp-tool-shape-hero.webp"
draft: false
---

import Callout from '@techsites/theme/components/Callout.astro'
import ComparisonTable from '@techsites/theme/components/ComparisonTable.astro'
import StepByStep from '@techsites/theme/components/StepByStep.astro'
import Figure from '@techsites/theme/components/Figure.astro'

Read the Dataverse MCP Server announcement as a feature and you miss the point. Read it as a warning and it snaps into focus.

Microsoft is telling you, politely, that the contract *you* define decides whether an AI agent acts safely inside your system of record. Not the platform. You.

That contract has a name in the Model Context Protocol world. It's the tool shape. And it's the most important governance decision you'll make this year that nobody scheduled a meeting about.

## What actually changed

Before MCP, an agent reaching Dataverse meant composing queries. FetchXML, SQL, whatever it could assemble from natural language. You were trusting an LLM to author the access pattern, and then trusting your security layer to catch whatever it got wrong.

The Model Context Protocol flips that. Each capability becomes a self-describing tool: a `name`, a `description`, a typed `inputSchema`, a structured result, and behavioral annotations that mark whether the action is read-only or destructive.

The agent no longer writes arbitrary queries. It invokes vetted, schema-bound actions. Metadata discovery, record read, CRUD, prompt and knowledge tools.

This narrows the error surface and the attack surface at the same time. But only if the tools are shaped tightly. A loosely shaped tool gives back everything you just took away.

<Callout type="info">
MCP is Anthropic's open protocol, not a Microsoft invention. That choice is the whole strategy, and we'll come back to it. The short version: the agent UI is being commoditized, the data plane is not.
</Callout>

## Tool shape is the first line, not the last

Here is the trap, and it's the one most teams will walk into.

People hear "schema-bound, governed tools" and assume the tool definition is the security boundary. It isn't. Tool shape is a first-line control. It shapes intent and narrows the surface. It is not the authoritative enforcement floor.

The real floor is still Dataverse. Security roles. Row-level security. Column-level security through Field Security Profiles. That machinery has guarded your data for years and it does not stop being the enforcement layer just because an agent is the caller.

But it only works under one condition: the agent has to run in the invoking user's delegated context.

That's the whole game in one sentence.

When the call carries the user's identity, row-level and column-level security travel with it. The agent sees exactly what that human would see. When the call runs under a broadly permissioned service principal instead, every per-user control evaporates. The agent sees everything the app registration can see, which is usually far too much.

Now combine the two failure modes:

- A broadly shaped tool ("execute any query")
- Running under a generously permissioned service principal

That collapses both layers at once. You've handed an LLM the keys to your system of record, and neither tool shape nor Dataverse security is standing in the way. This is the dominant failure mode, and it will not show up in a demo. It shows up six weeks later in an audit.

<ComparisonTable
  caption="Two governance layers, and what defeats each one"
  headers={["Layer", "What it enforces", "What collapses it"]}
  rows={[
    ["Tool shape (MCP contract)", "What an agent can request; typed inputs; read-only vs destructive intent", "A generic query-passthrough tool that accepts arbitrary operations"],
    ["Dataverse security (roles, RLS, CLS)", "What a given identity may read or write at row and column granularity", "Running under a service principal instead of delegated user context"],
    ["Both together", "Defense in depth: narrow intent enforced against per-user permissions", "Broad tool + over-permissioned app user. Both fail simultaneously"]
  ]}
/>

## Stop trusting the prompt

A predictable instinct is to write the guardrails into natural language. "Only return records the user owns." "Never delete." "Refuse sensitive columns."

Don't. Prompt-level instructions are guidance, not enforcement. They are bypassable by construction, and treating them as a control is how you end up explaining an incident to people who don't care about your system prompt.

Two things are trustworthy: schema-level constraints in the tool shape, and Dataverse-level enforcement under delegated identity. Everything else is a suggestion.

The takeaway is blunt. If a control can be talked out of, it isn't a control.

## The new risk class nobody budgeted for

MCP introduces a supply chain. Tools have definitions, definitions have metadata, and metadata flows into the model's context. That opens a category of attack that most Dataverse teams have never had to model.

- **Tool poisoning.** A malicious or careless tool definition shapes agent behavior in ways the author didn't intend.
- **Prompt injection through tool metadata.** The `description` field is not decoration. It's read by the model, and hostile content there can redirect behavior.
- **Confused deputy.** The agent, holding more authority than the request deserves, gets tricked into using it on someone else's behalf.

Treat every tool definition and every input as untrusted. The same way you'd treat a public API endpoint that anyone on the internet can call, because functionally that's closer to the truth than it feels.

## The competitive read

Here's the part that makes this strategic rather than just operational.

Microsoft could have built a Copilot-only walled garden. They didn't. They standardized on an open protocol, which means OpenAI, Claude, and your custom agents can all reach Dataverse through the same door.

That looks like giving something away. It isn't. It moves lock-in upward.

The agent and model layer becomes interchangeable, a commodity. The value-accruing assets stay exactly where Microsoft wants them: the tables, the business logic, Entra for identity, Purview for governance. Commoditize the agent UI, own the data plane.

If you're making platform bets, that's the signal. Don't over-invest in any single agent runtime. Invest in the substrate that every agent has to come through. Identity and governed data outlast whichever model is winning this quarter.

## What actually breaks when you turn it on

The hard work was never enabling the server. That's a switch.

The hard work is that almost no organization designed its schema or its security model for agent consumption. Your tables assumed a human in a form with a security role. Now the caller is a tireless, fast, occasionally hallucinating process that will invoke whatever you expose.

So the real project is a decision, table by table and action by action: which of these should *ever* be agent-callable? Most of them shouldn't be, at least not yet, and certainly not for writes.

## The first five moves

Do these in order. Each one assumes the previous is in place.

<StepByStep
  steps={[
    {
      title: "Default to delegated execution",
      body: "Run on-behalf-of the invoking user so row-level and column-level security travel with every call. If you can only do one thing from this list, do this one. Service principal execution should be a deliberate, reviewed exception, never the default."
    },
    {
      title: "Start read-only and narrow",
      body: "Expose specific, non-sensitive entities through purpose-built read tools. Refuse the temptation to ship a generic query-passthrough tool. The convenience is real and the blast radius is unacceptable."
    },
    {
      title: "Instrument logging before any write access",
      body: "Route to Sentinel or your SIEM with full provenance: which agent, which user context, which tool, which inputs. If you can't reconstruct who did what, you are not ready for writes."
    },
    {
      title: "Put a human in the loop for write and delete",
      body: "Destructive and mutating operations get a confirmation gate with a real person attached. The behavioral annotations in the tool shape tell you which operations these are. Use them."
    },
    {
      title: "Treat each tool as a published API",
      body: "Owner, version, data classification, and a review board before it ships. A tool definition that reaches your system of record deserves the same scrutiny as a public endpoint, because that is effectively what it is."
    }
  ]}
/>

## Where this leaves you

The Dataverse MCP Server is genuinely good engineering. It also quietly relocates a security boundary into a place most teams aren't looking: the tool contract, and the identity it runs under.

Get the shape tight and the identity delegated, and you get defense in depth that's better than what most orgs run today. Get either wrong, and you've connected a language model directly to your record of truth with the guardrails switched off.

Microsoft told you which one it is. The contract is yours to define.

<Callout type="warning">
This surface is evolving fast. Tool catalog names, GA versus preview status, and the precise delegated-versus-service-principal propagation semantics should be checked against current Microsoft Learn documentation before you design against them. The architecture principle holds; the exact knobs are still moving.
</Callout>