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.
- Getting started with DSC 3.0 – Part 1: What is DSC and what changed?
- Getting started with DSC 3.0 – Part 2: Managing a Windows service end to end
- Getting started with DSC 3.0 – Part 3: Capturing the current state with dsc config export
- Getting started with DSC 3.0 – Part 4: Configuring IIS with multiple resources and dependsOn
- Getting started with DSC 3.0 – Part 5: Guarding your configuration with Assertion
- Getting started with DSC 3.0 – Part 6: Using the DSC MCP server with your AI coding tools
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_resourceslists the resources on the machine,show_dsc_resourceshows one resource with its properties, andlist_dsc_functionslists 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_functionandinvoke_dsc_expression(both new in 3.3) let the assistant check a function or expression instead of guessing the result - Act:
invoke_dsc_resourceandinvoke_dsc_configcan run operations on your system. More about those below
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
dependsOnbetween 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 exportfrom 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 testanddsc config set --what-ifbefore 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.