Skip to main content

Getting started with DSC 3.0 – Part 6: Using the DSC MCP server with your AI coding tools

Throughout this series I ran into the same kind of problem again and again. Which resource type do I need? What is the exact name and casing of a property? Which adapter runs it? Names also change between versions. The Windows PowerShell adapter got a new name in 3.2, and the dsc mcp command became dsc server in 3.3.

An AI assistant that writes DSC YAML for you can easily get this wrong. It guesses, based on what it saw during training. DSC 3.0 has a built-in answer for that: an MCP server that lets the assistant ask DSC itself.

Note: this post is part of a bigger series on Microsoft Desired State Configuration.

DSC has an MCP server built in

You start it with:

dsc server

On DSC 3.2 the command was dsc mcp. From 3.3 on, mcp still works as an alias.

It talks over standard input and output. The AI tool starts the process and communicates with it, so you rarely run it by hand.

Remark: The Model Context Protocol is an open standard that connects AI agents to external tools and data. A server offers tools, and the AI tool, the client, calls them. Your AI coding tool is the client, and DSC is the server.

What tools does the DSC MCP server has to offer?

The tools fall into four groups:

  • Discover: list_dsc_resources lists the resources on the machine, show_dsc_resource shows one resource with its properties, and list_dsc_functions lists the configuration functions
  • Understand: show_dsc_schema (new in 3.3) returns the JSON schema for a configuration document, a resource or an output type
  • Evaluate: invoke_dsc_function and invoke_dsc_expression (both new in 3.3) let the assistant check a function or expression instead of guessing the result
  • Act: invoke_dsc_resource and invoke_dsc_config can run operations on your system. More about those below
Here is the list of tools as seen through the ModelContextInspector:


Why do we need this?

Take Part 4 of this series. We had to get the adapter name right, put requireAdapter on every instance, and use the exact property names of resources like WebSite and WebAppPool. With the server it can look those up on our machine instead of relying on memory.

Notice the last words: our machine. The server only knows the resources and adapters installed where it runs. Therefore, it is important to install the modules first, for example WebAdministrationDsc, or the assistant won't see them.

Set it up

Every client starts the same process. Only the JSON wrapper around it differs.

VS Code with GitHub Copilot

Create .vscode/mcp.json in your workspace:

{
  "servers": {
    "dsc": {
      "type": "stdio",
      "command": "dsc",
      "args": ["server"]
    }
  }
}

Open Copilot Chat in Agent mode, click the tools icon and check that the DSC server shows up in the list.

Claude Code

claude mcp add --scope project dsc -- dsc server

Everything after -- is the command that starts the server. With --scope project the entry is written to .mcp.json in your project root, so you can commit it and share it with your team. That file looks like this:

{
  "mcpServers": {
    "dsc": {
      "command": "dsc",
      "args": ["server"]
    }
  }
}

Run claude mcp list to verify the server is connected.

Try it

Give the agent a concrete task and tell it to use the server.  For example:

Write a DSC v3 configuration document in YAML that installs IIS on Windows Server, creates an application pool, a website on port 8080 and a web application. Use the DSC MCP server to check which resources and adapters are available and what their schemas look like. Use dependsOn between the resources. Don't run anything.

The agent should look up the resources first and then write the document. You can see each tool call in the client. Then do what we did in the earlier parts: run dsc config test and check the result before you apply anything.

Some other things to try:

  • Make sense of an export. Paste the output of dsc config export from Part 3 and ask the assistant to trim it into a desired-state document for the services you care about
  • Check an expression. Ask it to evaluate a configuration expression before you put it in your document
  • Explore. Ask what resources are available for a task, like the documentation's example "How can I manage Windows registry settings?"

Stay in control

An agent that can call invoke_dsc_resource can change your machine. A few habits keep this safe:

  • Mind the permissions. The server is started by your AI agent, so it runs with the permissions of that tool. Use a sandbox or limit the list of available tools.
  • Review the tool calls. Most clients ask for approval before a tool runs. Don't auto-approve the invoke tools.
  • Test first. Use dsc config test and dsc config set --what-if before a real set and try it on a test machine before production. The DSC documentation says this as well: always validate generated configurations in a test environment.
  • Read what it wrote. The assistant is guessing less, but it still guesses. You are responsible for the document that runs.

Wrapping up the series

We started with what DSC is and how 3.0 differs from the earlier versions. Then we managed a service, exported the current state, configured IIS with multiple resources and dependsOn, guarded a configuration with an assertion, and now let an AI assistant ask DSC for the facts.

DSC 3 is a completely different tool than the PowerShell DSC many of us know. Smaller, cross-platform, just data in YAML and in my opinion a lot easier to use.

There are some rough edges and the list of supported resources is still limited (but is growing). I have planned to write an extra post to share some of the issues (and solutions where available) that I encountered. 

I hope at least that this series made the switch a bit easier.

More information

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...