Introduction
This project was built to enable your AI tools, such as Windsurf, to use this MCP server to generate PowerShell Application Deployment Toolkit packages from scratch and more. The MCP server will retrieve the software installation information from GitHub, then use it to build the package.
https://github.com/kkaminsk/Packager-MCP
Having the MCP server download the latest PowerShell App Deployment Toolkit version 4.1.7 scripts wasn’t stable, so for now, the knowledge is caught on the MCP server itself. The upside is better version control, but the downside is tracking and following updates.
For those of you new to using the PowerShell App Deployment Toolkit, this can be a fantastic learning experience because not only do you get help packaging, but you can flip the chat window from code to chat mode in Windsurf (or whatever MCP client) and ask questions about the package or PowerShell App Deployment Toolkit.
The initial setup is a bit involved, so you might want to do this on a development virtual machine with a snapshot you can go back to. Sometimes I use a Windows 365 Cloud PC for development, but it’s up to you and your circumstances.
You can use editors like VS Code or Windsurf to edit the project files after building the package, but due to hallucinations, I’ve had to work around them a bit. This is where I’ll use Claude CLI to make the package files.
Prerequisites
Introduction
Be prepared, as you might be blindly following some steps. These tools were very new to me as well, and setting up an MCP server is excellent when it works, but making it work requires a lot of guidance, which isn’t always available. In this section, I’ll explain how to install the necessary prerequisites as simply as possible for someone with a new Windows 11 development virtual machine.
Accounts
Claude CLI: Essentially a command-line version of Claude. It can be helpful to run commands in multiple terminal windows. In this example, we will code from the command line.
(Bonus: I have three codes to give away using this link for one week of Claude free. https://claude.ai/referral/XEAnnFNZIA
GitHub: Connect to the Winget repository for the latest information on software installers and scripts.
Installation of Software
Install Git
PowerShell / Bat
winget install git.git
After running the Git install, you may be prompted to approve the repository if this is the first time using it on the machine. Press Y then return.
Then you will see a success message after installing the software.
Now install Node.JS 21.
PowerShell / Bat
winget install OpenJS.NodeJS.21
Next, we will make a place for the MCP server to be installed. You can pick almost any location, but we will make our own folder. Off the root is called MCP.
PowerShell / Bat
cd c:\
mkdir MCP
Next, we need to download the MCP. But before that, CLOSE AND RE-OPEN your PowerShell, Windows Terminal or Command Prompt to get the latest environment variables.
MCP Install
The installation of the MCP largely involves downloading the project from GitHub, then installing the required dependencies. To do this, go back to the folder for the next steps, installing the MCP Server.
PowerShell / Bat
cd c:\mcp
PowerShell / Bat
<Rewrite the command in lower case or it will fail>
Wrong:
GIT CLONE HTTPS://GITHUB.COM/KKAMINSK/PACKAGER-MCP.GIT
Correct:
git clone https://github.com/kkaminsk/packager-mcp.git
Go into the folder you downloaded and begin the installation of required libraries such as the MCP SDK and Zod. They are not part of the repository so this is required for every MCP installation.
PowerShell / Bat
cd .\packager-mcp\
npm install
NPM will then complete, and we can move on to compiling the TypeScript code, and the build process also copies the knowledge base and template files into the MCP server.
Now build the NPM solution.
PowerShell / Bat
npm run build
Claude CLI
When building the MCP packaging solution, I encountered hallucinations of V3 functions being used in the workflow. I generally use Claude CLI for coding, but for creating a package, it was the only agent I could reconfigure using the rules I had. Context and rules are defined in a Claude.md file that the agent reads to avoid issues during package generation. To install Claude CLI, try the following command.
PowerShell
irm https://claude.ai/install.ps1 | iex
The installer will give you a success message that can be misleading. If you look closely, you’ll need to add a path to your system environment variable.
To configure the environment variable for Claude, I provided a script in the Packaging_Files subfolder. Go to that folder and run the Set-ClaudeCLIEnv.ps1.
Close the prompt, as it will need to refresh environment variables.
MCP Configuration
This section outlines how we integrate the MCP server with the Claude CLI, which then sets up the solution for building packages. Luckily, the setup for Claude CLI is a single command line, so you are not left editing JSON configuration files as you would with other tools.
First, we need to obtain an API key for the MCP server, which uses the Winget repository to retrieve application information. By default, a key can view all public repositories, but you can choose to scope that more narrowly if need be.
GitHub Personal Access Token (API Key)
There really is only one API key to this solution, and this is to GitHub to ensure that information that is the least static, such as software installer versions and binaries, is retrieved for the highest quality package.
First, go to: https://github.com/settings/tokens?type=beta
Click Generate New Token.
Name the token something you will remember like Packager-MCP.
You can adjust the scope, but the default has sufficient permissions.
Scroll down and select Generate token.
Click Generate token.
Copy the token for the next steps.
Claude CLI Integration
The first step is to launch and configure Claude CLI. Before that, make sure you have an account, or select to create one during the Claude login workflow. In PowerShell, go to the root of the MCP server’s folder, i.e. C:\MCP\Packager-MCP. There, you will run the following using your own token.
claude mcp add packager-mcp node C:/MCP/Packager-MCP/dist/server.js -e GITHUB_TOKEN=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 🡨Replace with your token
Keep in mind that the MCP server is only for that session so don’t close it and forget to re-add the MCP server.
Next, let’s configure the rest of Claude to have a login.
PowerShell / Bat
Claude
Press enter to accept dark mode, then select the Claude account with a subscription.
Select Continue with Google when your browser launches.
Enter your account name, then select Next.
Perform MFA and click Continue.
Click Authorize.
If you go back to Claude CLI it should be activated.
You will receive notifications about security risks when using Claude. This further reinforces the use of a test or virtual machine when using this tool.
Make sure to allow Claude to write to its configuration file.
Once Claude is loaded, I’ll enter CTRL + C twice to break out of it.
Before packaging, make sure the MCP server is active for the project by running the following command in the C:\Temp\WinRAR folder.
PowerShell / Bat
claude mcp add packager-mcp node C:/MCP/Packager-MCP/dist/server.js -e GITHUB_TOKEN=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
Building the Package
As you can see, it took a fair bit of work to get here, so I recommend having a virtual machine with a development environment and snapshots to work with this as a packaging tool. The setup time decreases with practice, but it is still a manual process to install the MCP and agent.
Now let’s build the actual package. I am still tweaking prompts so there isn’t necessarily a right or wrong way, but the output must be bug-free to be usable.
In this example, I might be paranoid, but I absolutely want to make sure that the context provided in the Claude.md file is read and used. I start by asking Claude to read the claude.md file for context.
Prompt:
Read the @Claude.md file for context
The file will be read and stored in memory.
The next step may no longer be critical, but I insisted that the agent use the MCP to build the package. You can play with the prompt, but this, I know, gives me what I want.
The first bit calling out the following prompt snippet:
Prompt:
Use Packager-MCP
The above might be overkill but the prompt enforces that I want a package using the MCP server I installed.
Step 1: Depending on the outcome, the AI may receive the beta or the latest version of WinRAR, unless I specify otherwise in the prompt.
Step 2 might not be needed as much, but given the hallucinations, I wanted to force this MCP to use PSADT 4.17, and then I’ll update its local KB as required. The output folder is also specified, so you don’t have to build the package in the root folder.
Step 3: suggested ensuring the agent reviews their work. As shown in the workflow, it retrieves information from the MCP, applies hallucinations to “fix” it, applies the rules in Claude.md, and then fixes the code issues.
Step 4: might break with larger installers, but since it has the information, why not download the installer?
Step 5: I burn a bunch of extra tokens to produce documentation. I could be much more specific about the document structure, but for now, this makes a decent document.
Use Packager-MCP 1 I want a package with the latest WinRAR version. Exclude beta versions. 2. Use get_psadt_template with .\TEST_WinRAR_Package to generate the template files 3. If issues are found, report them so they can be corrected 4. Download the installer to the Files folder using Invoke-WebRequest 5. Make an extensive Readme.md for the package.
Once the prompt is pasted, you can simply press return.
It will begin processing the request and look for signs that it is making tool calls to the MCP, so you know it is working with the correct data. For example, this one tries to use the MCP server but fails and prompts a web search. Avoid web searches as they can lead to prompt injections.
You can exit the process by pressing Ctrl+C twice or selecting option 3, then you can also ask Claude to verify the MCP installation for you.
Successful tool usage should look more like this.
If the MCP is functional, you will be prompted to approve a command that Claude CLI wants to run in the console. Do take a moment to read them before agreeing.
After many prompts, you will complete the generation process.
At this point, you can press CTL+C twice to exit and run the Invoke-PowerShellAppDeploymentToolkit.ps1 in the WinRAR_Package folder. Or you can launch an elevated PowerShell prompt to test the package.
And if the planets align (sorry, lots of failed tests…) you will have an installable package.
Closing Notes
This required considerable persistence to sort out. Just when I thought I had built the MCP server, I realised the output only looked good and wasn’t usable. I had to learn how best to address the fact that, as good as Claude is, it didn’t have the correct training data and was trying to be too helpful by correcting code that used deprecated PSADT V3 functions. I was hoping to make this simpler from an AI perspective, but the journey required me to find ways to fix the AI’s behaviour.
I was hoping to do away with the Claude.md file in the future, but I expect it will serve as a set of guardrails for making packages. Different agents use different files, but I chose this approach because I am familiar with the tools and it produces the correct output. I tried other tools/methods, but I wasn’t getting the results I was hoping for. At the end of the day, the MCP server doesn’t care what connects to it.
If you are curious about the claude.md file, you can find the secret sauce to fixing it over here.
## The Problem: AI Training Data Contains INCORRECT Function Names
AI models (including you) have been trained on outdated or incorrect PSADT function names. These functions **DO NOT EXIST** in PSADT v4.1.7 and will cause runtime errors:
### Functions That DO NOT EXIST (but are in your training data) | WRONG - DO NOT USE | CORRECT - USE THIS | |--------------------|-------------------| | `Initialize-ADTDeployment` | `Open-ADTSession` | | `Complete-ADTDeployment` | `Close-ADTSession` | | `Get-ADTInstalledApplication` | `Get-ADTApplication` | | `Execute-Process` | `Start-ADTProcess` | | `Execute-MSI` | `Start-ADTMsiProcess` | | `Show-InstallationWelcome` | `Show-ADTInstallationWelcome` | | `Show-InstallationProgress` | `Show-ADTInstallationProgress` | | `-Arguments` parameter | `-ArgumentList` parameter | | `Close-ADTSession -DeploymentStatus` | `Close-ADTSession` (no parameters) | | `Close-ADTSession -ErrorMessage` | `Close-ADTSession` (no parameters) | | `-CloseApps` parameter | `-CloseProcesses` parameter | | `-CloseAppsCountdown` parameter | `-CloseProcessesCountdown` parameter | | `-PersistPrompt` with `-CloseProcesses` | Remove - causes parameter set conflict | | `-BlockExecution` with `-CloseProcesses` | Remove - causes parameter set conflict | | `$ADTSession.FilesDirectory` | `(Get-ADTSession).DirFiles` | | `$ADTSession.DirFiles` | `(Get-ADTSession).DirFiles` | | `$ADTSession.<Property>` | `(Get-ADTSession).<Property>` | **If you use any function from the "WRONG" column, the script will fail with:** ``` The term 'Initialize-ADTDeployment' is not recognized as the name of a cmdlet ``` **If you use invalid parameters on Close-ADTSession, the script will fail with:** ``` A parameter cannot be found that matches parameter name 'DeploymentStatus' ``` **If you use old parameter names on Show-ADTInstallationWelcome, the script will fail with:** ``` The parameter set cannot be resolved using the specified named parameters ``` **If you use `$ADTSession` variable directly, the script will fail with:** ``` Cannot bind argument to parameter 'Path' because it is null ```
What opened my eyes was that it’s not only the models you use but also the tools that use the MCP servers. From my perspective, MCP servers are the wild west, and installing them where they make the most sense is a bit of a trial-and-error process. Often, I find myself downloading code from GitHub and fixing stale API calls when finding an MCP server, but there is a growing list of better-maintained servers to use.
And this is where I talk about AI for sysadmins, as a toolbox. Right now, it’s hard to keep up with all the start-ups and giants trying to carve up market share. News releases are frantic, but try to pilot and evaluate tools for your needs, and remember that things are still very early. For code generation, I see promise: most code isn’t interesting, so why not have assistants build it with supervision?
Remember that I left this at 0.8 for now, as I want to see more scenarios tested before I trust it more. My short-term focus was building a package using a prompt, but more can be done with this MCP. Remember to check GitHub for the server source code and the distribution folder.
https://github.com/kkaminsk/Packager-MCP
