MCP Server

The Power Portals Pro MCP server gives AI coding assistants first-hand knowledge of this framework while you build. It is a Model Context Protocol server, it ships with the framework, and there is no licence key and nothing to sign up for.

Why it exists

Two things an agent cannot get from documentation alone, and both of them cause broken code:

What it answers

Note

Every Dataverse tool reads metadata. None of them reads, writes or deletes a record, so pointing an agent at a production environment lets it learn the shape of your data without being able to touch it.

Adding it to a project

Two places it can live

There is a chicken-and-egg here worth being explicit about. The templates write the configuration into the project they create — but the server is at its most useful before that project exists, when you are choosing a template and its options. So install it once for yourself, and let the per-project file take over from there.

Once per machine, for any folder

This makes the server available everywhere, including an empty folder you are about to scaffold into. It can then answer which template to use, what the options mean, and what to configure afterwards. Deliberately unpinned, so it tracks the latest release:

Visual Studio reads a user-level .mcp.json from your profile folder, Cursor uses ~/.cursor/mcp.json, and VS Code has a user-level MCP configuration in its settings. Each takes the same servers block.

Per project, pinned to its version

Projects created from the Power Portals Pro templates are wired up already: the template writes a .mcp.json at the solution root, pinned to the matching server version. There is nothing to do.

To add it to an existing project, create that file yourself at the root of your solution:

Which file your editor reads

Visual Studio 2022 17.14+ and Visual Studio 2026 read .mcp.json from the solution folder, and so does Claude Code. VS Code reads .vscode/mcp.json and Cursor reads .cursor/mcp.json — both use the same servers block, so copy it across.

dnx ships with the .NET 10 SDK, which you already have: every Power Portals Pro project is hosted by ASP.NET Core, React SPAs included. The first run downloads the package and caches it.

Having both is the intended setup. The two entries use the same server name, so a client that understands both scopes uses the project's — which means you get the version-matched answers inside a project, and the latest ones anywhere else.

Checking it is working

Ask your assistant something only the server can answer — for example “use get_component_api to show me every parameter on MainGrid”. If the tool is not available, the client has not picked up the configuration file; most need a restart after it is added.

Connecting to Dataverse

The documentation tools need no configuration at all. The metadata tools need a connection to your environment, and that connection belongs to the folder, not to the machine. Run this once in the project:

One environment per folder

That binds this folder to one environment. If you work across several customers, every project stays signed in to its own environment and agents in different folders never cross over. This is the one thing pac auth select cannot do — it switches a single machine-wide profile, so changing customer in one place changes it everywhere.

Sign-in uses the device-code flow by default, so it works over SSH, inside a container and in WSL, and you can finish it on a phone. Pass --browser if you would rather open one.

Where things are stored

The token cache is keyed by environment, so a second clone of the same customer's repository does not ask you to sign in again, while a different customer always does.

Commands

All of these act on the current folder unless you pass --workspace.

Other ways to connect

The environment and credentials are resolved in this order, so the most explicit statement of intent wins:

  1. Environment variables — PPP_D365_URL, PPP_D365_CLIENT_ID and PPP_D365_CLIENT_SECRET in the server's env block. A service principal, and the way to wire this up in CI or a shared container.
  2. The folder's sign-in — written by login. The normal path.
  3. The project's own settings — the same D365:Url, D365:ClientId and D365:ClientSecret (or D365:Secret) the portal itself reads from user secrets and appsettings. A configured Power Portals Pro project therefore often needs no sign-in at all.

Power Platform CLI profiles

If you already keep environments in pac, you can start from one rather than hunting for a URL:

The CLI has no command that hands out an access token, and it keeps credentials in its own store, so its session cannot be reused directly. What --pac-profile does is take the environment and the account from a profile and sign in as that account — usually without prompting, because you already have a session.

Note

The CLI's own active profile is never changed. pac auth select is deliberately not used: it would move every project at once.

The tools

You rarely need to name a tool — assistants pick them from the descriptions — but it helps to know what is there.

Documentation, always available

Your environment, once connected

Getting a new project running

Working in other languages

The knowledge the server returns is English, and that is deliberate. Your assistant is the one reading it — you never see a tool response directly — so it translates for you: ask in your own language, and it answers in your own language. What it must not translate is the code. Component, parameter and column names are English in every project, whatever language the conversation is in, so keeping the reference English is what stops an assistant inventing a translated parameter name that does not exist.

Note

Questions that name something — “MainGrid Ansichten konfigurieren” — already work in any language, because component names are the same everywhere. The tools also tell your assistant to search in English, so questions that name nothing work too.

Troubleshooting