MCPServerPS

This project creates a PowerShell module that serves as a Model Context Protocol (MCP) server. The module exposes the Start-MyMCP cmdlet, which starts the MCP server and dynamically exposes tools based on how it is invoked.

MCP server as a PowerShell Module

Benefits of shipping an MCP server as a PowerShell module:

• Small size: 5.17 MB. Only the .NET MCP SDK assemblies are required.
• Availability: easy to distribute and install via PowerShell Gallery across platforms.
• Flexible: expose C# tools, .ps1 script tools, or module function tools.
• For an MCP server that needs PowerShell features, the runtime is naturally available (runs in pwsh.exe), so no need to ship PowerShell SDK assemblies.

Building the Module

To build the project, run:

dotnet publish .\src\MCPServerPS.csproj

The published module will be available at .\out\MCPServerPS.

After deploying the module to your PowerShell module path, you can start the MCP server using the Start-MyMCP cmdlet.

Start-MyMCP Cmdlet Parameter Sets

The Start-MyMCP cmdlet supports three parameter sets:

Start-MyMCP -Name  []
Start-MyMCP -Name  -ScriptRoot  []
Start-MyMCP -Name  -Module  []

• Name (mandatory, all parameter sets): the name the server reports as its MCP serverInfo.name. Since MCP clients (e.g. VS Code) prefer this self-reported name over the mcp.json config key for tool grouping/naming, use a distinct -Name per configured instance so multiple instances of this module remain distinguishable.
• Default: Start-MyMCP -Name exposes all MCP tools defined in the C# code of this assembly.
• ScriptRoot: Start-MyMCP -Name -ScriptRoot exposes each .ps1 script file in the specified directory as an MCP tool.
• Module: Start-MyMCP -Name -Module exposes each function within the specified module as an MCP tool.

Examples of script tools and module function tools can be found in the ./scripts folder.

Both script tools and module function tools use comment-based help to define the description and parameters for each tool. This ensures that tool metadata is discoverable and user-friendly.

Runspace Behavior

• Each script tool runs in its own dedicated Runspace, so they are isolated from each other.
• Module function tools share the same Runspace for the module, allowing changes to module state made by one function tool to be visible to others. This is because module functions are considered related and may need to share state.

Using MCPServerPS in VSCode

1. Exposing C# MCP Tools

{
    "servers": {
        "MCPServerPS": {
            "type": "stdio",
            "command": "pwsh",
            "args": [
                "-noprofile",
                "-c",
                "MCPServerPS\\Start-MyMCP -Name MCPServerPS"