Initial MCP Server implementation #5610

JohnMcPMS · 2025-07-22T00:06:37Z

Discussion on further MCP work: #5609

Change

This change adds an MCP server that provides two tools:

Find packages
- Searches for packages based on a single input value, returning information about each one found.
Install package
- Installs a package given a single input value, which is expected to be an identifier, name or moniker (same rules as winget CLI)

The package response looks like:

{
  "identifier":"Microsoft.VisualStudioCode",
  "name":"Microsoft Visual Studio Code",
  "catalog":"winget",
  "isInstalled":true,
  "installedVersion":"1.102.1",
  "installedLocation":"%LOCALAPPDATA%\\Programs\\Microsoft VS Code\\",  <- Is actually real path, not tokenized
  "isUpdateAvailable":false
}

Also includes:

A group policy that determines whether the MCP server is allowed to operate
An mcp command that helps with manually configuring an MCP client
A change to the default COM caller behavior that makes it only use the file name
- Also changes to not use the package family name if it is the same as the current process (so we can better differentiate our own callers)
A Version property on the PackageManager COM object that returns the version string as 1.2.3 or 1.2.3-preview.
- Start preferentially using this in the PowerShell module to get the version rather than running the CLI

Validation

I have ensured that the various portions of this change function within the context of the dev package.

Microsoft Reviewers: Open in CodeFlow

…her than full path

src/AppInstallerCLICore/Commands/ConfigureListCommand.cpp

src/AppInstallerCLIPackage/Shared/Strings/en-us/winget.resw

florelis · 2025-07-25T20:24:02Z

src/AppInstallerCLIPackage/Shared/Strings/en-us/winget.resw

-  <data name="ConfigurationEnableMessage" xml:space="preserve">
-    <value>Enable configuration components. Requires store access.</value>
+  <data name="ExtendedFeaturesEnableMessage" xml:space="preserve">
+    <value>Enable extended features. Requires store access.</value>


I'm a bit concerned about there being confusion between "experimental" and "extended" features, but I can't think of a better naming.

src/AppInstallerCommonCore/Runtime.cpp

florelis · 2025-07-25T20:28:26Z

src/AppInstallerSharedLib/Public/winget/Filesystem.h

@@ -119,4 +119,7 @@ namespace AppInstaller::Filesystem
    // Gets the PathDetails used for the given path.
    // This is exposed primarily to allow for testing, GetPathTo should be preferred.
    PathDetails GetPathDetailsFor(PathName path, bool forDisplay = false);
+
+    // Gets the path to the executable for the given process id.


Are HANDLEs just the process ID? 🤯
(Or is the comment wrong?)

The comment is wrong because I wrote it with process id at first and then changed it when I realized what I actually had to pass in. Might hold on changing it in case there aren't any other substantial issues.

florelis · 2025-07-25T21:35:15Z

src/WinGetMCPServer/WingetPackageTools.cs

+                }
+
+                // First attempt a more exact match
+                var findResult = FindForIdentifier(packageCatalog, identifier, expandedFields: false);


The search is using "FindForQuery", so it may return different results. I'm pretty sure people don't like that in the CLI, but I don't know how this ends up being called by the hosts to know if that would be an issue here.

The search tool does:

ID equals OR Name equals OR Moniker equals (what the CLI uses for "targeted" commands)

ID contains OR Name contains OR Moniker equals (a looser version to provide some flexibility to the agent)

only using option 2 if nothing is found with option 1.

The install tool does:

Id equals

Id equals OR Name equals OR Moniker equals

similarly falling back to 2 only if nothing is found with 1.

The expectation is that the agent will always use the search tool to gather information, then use the result from that to inform the identifier field to use in the install tool.

src/WinGetMCPServer/WingetPackageTools.cs

florelis · 2025-07-25T21:38:33Z

src/WinGetMCPServer/Response/FindPackageResult.cs

+
+        public string? InstalledLocation { get; set; }
+
+        public bool? IsUpdateAvailable { get; set; }


We don't include the available version?

COM doesn't provide it easily.

florelis · 2025-07-25T21:42:41Z

src/WinGetMCPServer/Response/InstallOperationResult.cs

+        public string? Message { get; set; }
+
+        public bool? RebootRequired { get; set; }
+
+        public int? ErrorCode { get; set; }
+
+        public uint? InstallerErrorCode { get; set; }
+
+        public FindPackageResult? InstalledPackageInformation { get; set; }


Does MCP allow us to say what any of these mean?

No, as far as I know, there is no ability to provide output schemas, despite the MCP documentation suggesting that you should have them.

florelis · 2025-07-25T21:45:33Z

src/WinGetMCPServer/Response/InstallOperationResult.cs

+    {
+        public string? Message { get; set; }
+
+        public bool? RebootRequired { get; set; }


We have information about this in the manifest, right? Could we report it ahead of time using the progress message? I think it would be nice to not get that information at the very end.

If I can get it in the search results, then I will add it there so that the agent can better reason over that fact.

florelis · 2025-07-25T22:33:04Z

Is this not going to be behind an experimental feature?

florelis · 2025-07-25T22:34:57Z

Also, I'd really appreciate it if you could update doc/ReleaseNotes.md with this feature

JohnMcPMS · 2025-07-25T23:00:57Z

Is this not going to be behind an experimental feature?

I don't see it as needed given that the user needs to opt-in to using it by manually configuring their client. The implementation of that block would either require reading the config in the MCP server or hacking in a check based on the caller info.

@denelon for opinion.

yao-msft · 2025-07-25T22:52:55Z

doc/admx/DesktopAppInstaller.admx

@@ -176,6 +176,16 @@
        <decimal value="0" />
      </disabledValue>
    </policy>
+    <policy name="EnableWindowsPackageManagerMcpServer" class="Machine" displayName="$(string.EnableWindowsPackageManagerMcpServer)" explainText="$(string.EnableWindowsPackageManagerMcpServerExplanation)" key="Software\Policies\Microsoft\Windows\AppInstaller" valueName="EnableWindowsPackageManagerMcpServer">


In case we have not done it, we'll need to talk to policy team about updating the policy template later.

yao-msft · 2025-07-25T22:55:07Z

src/Directory.Packages.props

    <PackageVersion Include="Microsoft.CSharp" Version="4.7.0" />
    <PackageVersion Include="Microsoft.Msix.Utils" Version="2.1.1" />
    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="17.3.2" />
    <PackageVersion Include="Microsoft.PowerShell.SDK" Version="7.4.6" />
    <PackageVersion Include="Microsoft.Win32.Registry" Version="5.0.0" />
    <PackageVersion Include="Microsoft.Windows.CsWinRT" Version="2.1.6" />
    <PackageVersion Include="Microsoft.Windows.SDK.Contracts" Version="10.0.26100.1742" />
+    <PackageVersion Include="ModelContextProtocol" Version="0.2.0-preview.3" />


nit: do we want to add a todo to update to stable version later?

yao-msft · 2025-07-25T22:57:21Z

src/AppInstallerCLICore/ConfigureExportCommand.cpp

@@ -3,6 +3,7 @@
 #include "pch.h"
 #include "ConfigureExportCommand.h"
 #include "Workflows/ConfigurationFlow.h"
+#include "Workflows/MSStoreInstallerHandler.h"


Now I'm wondering, why did we not put this command under Commands folder ...

yao-msft · 2025-07-25T23:15:11Z

src/Microsoft.Management.Deployment/Helpers.cpp

-            if (SUCCEEDED(wil::QueryFullProcessImageNameW(processHandle.get(), 0, imageName)) &&
-                (imageName.get() != nullptr))
+            std::filesystem::path executablePath = AppInstaller::Filesystem::GetExecutablePathForProcess(processHandle.get());
+            if (executablePath.has_filename())


If the executable path does not have file name, should we return the full path instead of empty?

I don't think so; that sounds like an error and logging would be appropriate.

yao-msft · 2025-07-25T23:33:44Z

src/WinGetMCPServer/WingetPackageTools.cs

+    using Microsoft.Management.Deployment;
+    using ModelContextProtocol.Protocol;
+    using ModelContextProtocol.Server;
+    using System.ComponentModel;


nit: I guess Stylecop is not turned on for this project? It should complain that System. should be on the top.

yao-msft · 2025-07-25T23:45:55Z

src/WinGetMCPServer/Program.cs

+                .WithStdioServerTransport()
+                .WithTools<WingetPackageTools>();
+
+            builder.Build().Run();


Does this handle shutdown events automagically by the framework?

No, I doubt it, but I had thought of that. Maybe my change to improve our quiesce story should include an event to make it easier for clients to act appropriately without needing to re-implement the entire "window to listen for shutdown messages".

JohnMcPMS added 15 commits June 17, 2025 15:45

adding MCP server poc

2d98c5e

Add CsWinRT ref

1474d94

remove comment

3051b17

Move toward single file trimmed server

3fb9aa3

Fix improper inclusion of .lib

ae2e40f

Integrate with package

70d9bb9

Refactoring

12c9b94

More refactoring

78d58b1

Refactoring

aa0e9a8

Add Version property to COM and consume it from MCP and PS

431defd

Exception to tool response handler; telemetry updates

556ebc9

Add function to retrieve path and use it to only return file name rat…

5802d3a

…her than full path

Add test for path retrieval

a006bc2

Add mcp command to help with manual config

16c46fd

Add GP for MCP server

33cd89a

JohnMcPMS mentioned this pull request Jul 22, 2025

MCP Server (Package tool) #5528

Open

JohnMcPMS added 2 commits July 22, 2025 15:46

Merge from master

8de3589

Add to missed test list

21f92a0

florelis previously approved these changes Jul 25, 2025

View reviewed changes

yao-msft reviewed Jul 25, 2025

View reviewed changes

yao-msft previously approved these changes Jul 25, 2025

View reviewed changes

PR feedback

413431c

JohnMcPMS dismissed stale reviews from yao-msft and florelis via 413431c July 26, 2025 00:12

florelis approved these changes Jul 26, 2025

View reviewed changes

JohnMcPMS merged commit eaab1bf into microsoft:master Jul 26, 2025
9 checks passed

JohnMcPMS deleted the mcp-poc branch July 26, 2025 17:07


		public string? InstalledLocation { get; set; }

		public bool? IsUpdateAvailable { get; set; }

Initial MCP Server implementation #5610

Initial MCP Server implementation #5610

Uh oh!

Conversation

JohnMcPMS commented Jul 22, 2025 • edited by microsoft-github-policy-service bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change

Validation

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

florelis commented Jul 25, 2025

Uh oh!

florelis commented Jul 25, 2025

Uh oh!

JohnMcPMS commented Jul 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JohnMcPMS commented Jul 22, 2025 •

edited by microsoft-github-policy-service bot

Loading