dataverse-modelling-mcp

A local Model Context Protocol server that lets AI clients (Claude Code, GitHub Copilot, …) model Dataverse and the Power Platform — not just read and write records, but build the schema, the views, forms and command bar, the security roles, the processes and the solutions around them.

117 tools across Tables & Columns, Views, Forms, Security Roles, Solutions/ALM, Solution Pipelines, Classic Workflows, Business Process Flows, Cloud Flows, Modern Commands, Classic Ribbons, Web Resources, Environment Variables and Analysis — all via delegated user auth (no secrets, no service accounts), with a read-only mode, a production guard and dry runs.

dotnet tool install -g Dataverse.ModellingMcp.Setup   # then: dataverse-modelling-mcp

→ Quickstart · Security & safety · Why not Microsoft's Dataverse MCP server?

Tools

Plus dataverse_submit_feedback — an optional telemetry tool that is inert unless the server operator has configured Application Insights. See Telemetry below.

Adding a button to a command bar? Read
Classic ribbon vs modern command first. It covers which
mechanism to pick, how a ribbon is really stored (and therefore how to remove a button, which a
solution import cannot do), and the dozen ways both mechanisms fail completely silently.

Quickstart

You need two things, whichever way you install:

• A Dataverse / Power Platform environment — preferably a dev or trial environment, not production.
• An Azure AD app registration that is a public client with redirect URI http://localhost and
  the delegated Dataverse permission user_impersonation (details in
  docs/authentication.md). The setup wizard
  in option B creates one for you if the Azure CLI
  is installed.

A. Claude Code plugin (Windows, macOS, Linux)

Inside Claude Code:

/plugin marketplace add hydr/dataverse-modelling-mcp
/plugin install dataverse-modelling-mcp@dataverse-modelling

Claude Code asks for the environment URL and the app's client ID. On the first server start the
plugin downloads the server binary from the latest GitHub release — no .NET SDK, no clone. The first
tool call opens a browser for sign-in. The plugin also brings the skills.

Binaries are published for Windows x64, macOS (Apple Silicon and Intel) and Linux x64.

B. dotnet tool (Windows, macOS, Linux — any MCP client)

Requires the .NET 8 SDK.

dotnet tool install -g Dataverse.ModellingMcp.Setup
dataverse-modelling-mcp            # setup wizard: app registration, sign-in, environment
claude mcp add dataverse-modelling-mcp -- dataverse-modelling-mcp server

The wizard:

1. Optionally creates or locates an Azure AD app registration via the Azure CLI
2. Opens a browser for interactive sign-in (delegated auth — no secret required)
3. Asks for the environment URL, environment ID and region
4. Writes config.json and caches the token in the OS keychain / DPAPI
5. Prints the claude mcp add command

Any other MCP client (GitHub Copilot, Cursor, …) starts the server with the command
dataverse-modelling-mcp server over stdio.

C. From source

git clone https://github.com/hydr/dataverse-modelling-mcp
cd dataverse-modelling-mcp
dotnet run --project src/Dataverse.Setup
claude mcp add dataverse-modelling-mcp -- dotnet run --project /path/to/src/Dataverse.Server

Configuration

The server reads config.json, written by the setup wizard:

Without a config.json it falls back to environment variables — this is how the plugin passes its
settings. The two safety switches at the bottom also apply on top of a config.json:

Security & safety

"An AI changes my Dataverse schema?" — yes, and this is what keeps that in bounds:

Two honest limits: the production guard checks the environment type on the first write and lets
the call through (with a warning on stderr) if Dataverse does not reveal the type. And delegated
rights cut both ways — in an environment where you are System Administrator, so is the AI. A
dedicated dev environment is still the best guard.

Why not Microsoft's Dataverse MCP server?

Microsoft ships an official Dataverse MCP server.
It is a good product — for a different job. It is built around data: search, SQL queries,
record CRUD, files. This server is built around modelling: everything a maker or developer
does in the solution explorer. The two work side by side.

¹ Microsoft's separate Dataverse skills plugin covers solution
handling through the PAC CLI.

Rule of thumb: use Microsoft's server when an agent should work with the data in Dataverse
— in production, supported by Microsoft. Use this one when an agent should build in a dev
environment: tables, columns, views, roles, processes, solutions. Then promote the solution like
any other.

Comparison as of October 2026, based on Microsoft Learn (tools and billing,
non-Microsoft clients,
configuration). Microsoft's tool set has
changed before — check the links for the current state, and open an issue if this table is out of date.

Authentication

Tokens are acquired via MSAL PublicClientApplication (silent first, browser fallback) and persisted platform-natively:

No client secrets are ever stored. See docs/authentication.md for full details.

Architecture

AI Client (Claude Code / Copilot)
          │ MCP stdio
  Dataverse.Server          — thin MCP tool wrappers
          │
  Dataverse.Core            — services, HTTP clients, auth, models
          │ HTTP
  Dataverse Web API v9.2
  Power Automate Flow API
  BAP API

See docs/architecture.md for the full diagram and design principles.

Development

# Build
dotnet build

# Unit tests
dotnet test

# Integration tests (requires a configured environment)
$env:DATAVERSE_INTEGRATION_TESTS = "true"
dotnet test

# Run the MCP server locally
dotnet run --project src/Dataverse.Server

Integration tests connect to the environment configured in config.json and expect a sample_mcptest table, a DV MCP Test Role security role, and a DV MCP Test solution to exist.

Updating to a new release (no session restart needed)

When installed as a Claude Code plugin, the server binary is not started directly —
.mcp.json launches scripts/launch (the shell script on macOS/Linux, launch.cmd → run-server.ps1
on Windows), which installs the binary version pinned in
scripts/BINARY_VERSION (skipping the download when it is already there) and then execs it,
passing stdio straight through.

So after a new release, getting the new tools takes:

1. Update the plugin so scripts/BINARY_VERSION points at the new version (/plugin → update,
   or however the marketplace entry is refreshed).
2. Open the /mcp menu, pick dataverse-modelling, and choose Reconnect.

That restarts the server process, which re-runs the launcher and picks up the new binary — no
new Claude Code session required. The SessionStart hook (scripts/ensure-binary.*) still
pre-warms the download; because both paths share scripts/binary-common.* and short-circuit
when the expected version is already installed, nothing is downloaded twice.

Binaries live in versioned directories (<plugin-data>/bin/<version>/DataverseMcp[.exe]) so an
update never has to overwrite a running .exe — which Windows would refuse while another
session still has it open.

Docs

• Setup guide
• Architecture
• Authentication
• Tool reference
• Analysis — dependencies and solution membership
• Forms — structure, code components, FormXML pitfalls
• Command bar buttons — classic ribbon vs modern command
• Modern commands (appaction) — field semantics and gotchas
• Contributing · Security policy

Skills

Skills load automatically when a conversation touches their subject — they exist so the hard-won
parts of the docs above surface without anyone having to know they exist.

They ship in skills/, which travels with the plugin and is therefore active in every repo the
plugin is installed in — as opposed to .claude/skills/, which would scope them to this repository,
the one place the Dataverse advice is least needed.

Telemetry

The server exposes one optional telemetry tool, dataverse_submit_feedback, which an AI client may
call to send session feedback (free text, a category, an optional severity and an optional session summary)
as a single Application Insights event.

It is off by default and off for anyone who just clones this repo. Telemetry is transmitted only
when the process is started with the standard APPLICATIONINSIGHTS_CONNECTION_STRING environment
variable pointing at an Application Insights resource. When that variable is unset — the default —
the underlying client is a no-op: calling the tool logs locally and sends nothing over the network.
No connection string is bundled with the server.

If you run the server yourself and do not want this endpoint at all, leave
APPLICATIONINSIGHTS_CONNECTION_STRING unset (nothing is sent) or remove
src/Dataverse.Server/Tools/FeedbackTool.cs and rebuild. What is sent, when configured, is exactly
the fields above plus constant/derived metadata (schema version, server tag, server version, transport stdio,
the fixed caller local-stdio, and the MCP client name and version from the initialize handshake) — no user names,
auth tokens, org URLs, or record data.

CI

GitHub Actions runs dotnet build and dotnet test (unit tests only) on every pull request. See .github/workflows/ci.yml.

License

MIT © Crossvertise GmbH.