Add MCP Support to the ironmansoftware.powershell-universal ext

[Omzig]

Summary of the new feature / enhancement

• add mcp support just like MSSQL extension
• use the connection to connect to said instance
• do not make an MCP server stand alone

Extension:

• https://marketplace.visualstudio.com/items?itemName=ironmansoftware.powershell-universal

Proposed technical implementation details (optional)

Example Enhancement Plan

---

Add MCP Support to PowerShell Pro Tools VS Code Extension

Objective

Add Model Context Protocol (MCP) support to the PowerShell Pro Tools VS Code extension so that a connected PowerShell Universal (PSU) instance is surfaced as a documentation and context server — similar to Context7 or the Microsoft Docs MCP server. The MCP server MUST NOT be standalone; it MUST be embedded in the extension and use the existing connection infrastructure to communicate with the PSU instance. The MCP documentation and discovery surface MUST live under the dedicated /mcp/ namespace so it is clearly separated from the rest of the PSU management APIs.

Key Requirements

1. Embedded MCP Server — You MUST NOT create a separate standalone MCP server process. The extension itself MUST register MCP server definitions and/or language model tools that proxy through to the PSU instance. All MCP-facing documentation and discovery routes MUST be exposed under /mcp/ so they are clearly separated from the operational management APIs.
2. Use the Existing Connection — The extension already connects to the PowerShell host process via named pipes (PowerShellService in src/services/powershellservice.ts). For MCP, you MUST use the PSU instance's HTTP APIs and leverage connection settings (URL, app token) from VS Code configuration. Source operational data may come from the PSU management API (e.g., http://<host>:<port>/api/v1/), but the documentation-oriented MCP surface MUST be rooted at http://<host>:<port>/mcp/. You MUST NOT require users to configure a separate connection for MCP.
3. Documentation Server Pattern — The MCP integration MUST surface PSU server information as documentation context that AI agents can consume. This means providing tools/resources that return:
   • Cmdlet documentation (available PSU cmdlets, their parameters, and usage)

• Module reference (fast module overviews, exported cmdlets, aliases, common usage patterns)
• API endpoint definitions (registered REST endpoints, their routes, methods, and documentation)
• Dashboard/App component catalog (available UD components, their parameters)
• Script inventory (registered scripts, schedules, and their metadata)
• Platform configuration (environments, variables, roles, settings)
• Debugging guidance (breakpoints, tracing, logs, troubleshooting patterns)
• Scope guidance (global, script, local, private, runspace, and PSU execution context behavior)
• Common coding practices (recommended PowerShell patterns, error handling, output contracts, security, and module organization)

4. Discovery-First Design — Anything that requires discovery MUST be modeled under /mcp/discovery/. Discovery endpoints MUST give an agent the information it needs to write code correctly, including signatures, parameter metadata, payload shape, response shape, related cmdlets, examples, and any constraints needed for generation.
5. Swagger for Copilot Agents — Treat the /mcp/discovery/ surface as Swagger or OpenAPI for Copilot agents. It MUST be optimized for machine-guided understanding, not just prose. Discovery responses SHOULD be structured, stable, and high-signal so an agent can retrieve endpoint or script signatures and immediately generate correct calling code.
6. Fast Module and Cmdlet Understanding — The documentation server MUST provide a very fast path for understanding module cmdlets. It MUST expose a compact module and cmdlet reference index so AI tools can quickly answer questions like "what does this module export?", "which cmdlet should I use?", and "what are the important parameters?" without having to crawl raw help content on every request.
7. Follow the MSSQL Extension Pattern — Use vscode.lm.registerTool() to register individual language model tools, similar to how the MSSQL extension registers tools like mssql_connect, mssql_list_servers, mssql_run_query, etc. Each tool MUST implement the LanguageModelTool<T> interface.

Architecture

Overview

┌─────────────────────────────────────────────────┐
│  VS Code Extension (powershellprotools)          │
│                                                   │
│  extension.ts                                     │
│    └── registerLanguageModelTools()               │
│          ├── psu_connect          (connect to PSU) │
│          ├── psu_list_endpoints   (API endpoints)  │
│          ├── psu_list_scripts     (scripts/jobs)   │
│          ├── psu_list_apps        (dashboards)     │
│          ├── psu_get_cmdlet_help  (cmdlet docs)    │
│          ├── psu_get_config       (platform info)  │
│          └── psu_run_script       (execute script) │
│                                                   │
│  McpServerDefinitionProvider                      │
│    └── provides McpHttpServerDefinition            │
│        pointing at PSU MCP documentation API       │
│                                                   │
│  PsuApiClient (new)                               │
│    └── HTTP client wrapping PSU /mcp/ surface      │
│        uses configured URL + AppToken              │
└────────────────┬────────────────────────────────┘
                 │ HTTP (PSU /mcp/ + backing PSU APIs)
                 ▼
┌─────────────────────────────────────────────────┐
│  PowerShell Universal Server                     │
│  http://<host>:<port>/mcp/                       │
│                                                   │
│  /mcp/endpoints      (endpoint documentation)     │
│  /mcp/scripts        (script inventory docs)      │
│  /mcp/apps           (dashboard or app docs)      │
│  /mcp/modules        (module reference index)     │
│  /mcp/cmdlets        (fast cmdlet lookup)         │
│  /mcp/debugging      (debug guidance)             │
│  /mcp/scopes         (scope behavior)             │
│  /mcp/practices      (coding practices)           │
│  /mcp/config         (platform configuration)     │
│  /mcp/discovery/     (agent-oriented signatures)  │
│    ├── endpoints     (endpoint generation schema) │
│    ├── scripts       (script generation schema)   │
│    ├── apps          (app generation schema)      │
│    ├── modules       (module export schema)       │
│    └── cmdlets       (cmdlet signature schema)    │
└─────────────────────────────────────────────────┘

File Structure

You MUST create the following new files under vscode/powershellprotools/src/:

src/
  mcp/
    psuApiClient.ts            # HTTP client for PSU /mcp/ docs and discovery APIs
    mcpServerProvider.ts       # McpServerDefinitionProvider implementation
    tools/
      toolBase.ts              # Base class for all PSU LM tools
      connectTool.ts           # psu_connect — connect/authenticate to PSU
      listEndpointsTool.ts     # psu_list_endpoints — list API endpoints
      listScriptsTool.ts       # psu_list_scripts — list scripts and schedules
      listAppsTool.ts          # psu_list_apps — list dashboards/apps
      getCmdletHelpTool.ts     # psu_get_cmdlet_help — get cmdlet documentation
      getConfigTool.ts         # psu_get_config — get platform configuration
      runScriptTool.ts         # psu_run_script — execute a script on PSU

You MUST also modify these existing files:

• src/extension.ts — register MCP tools and provider during activation
• src/settings.ts — add PSU connection settings (URL, appToken)
• package.json — bump VS Code engine, add configuration, add tool contributions

Implementation Details

1. Bump VS Code Engine and TypeScript Target

The current extension targets vscode: ^1.46.0 and @types/vscode: ^1.46.0. The vscode.lm namespace (including registerTool, registerMcpServerDefinitionProvider, McpHttpServerDefinition) requires VS Code 1.99+ (the MCP server definition API is very recent).

You MUST:

• Update package.json engines.vscode to ^1.99.0
• Update devDependencies @types/vscode to ^1.99.0
• Update tsconfig.json target to es2022 and lib to ["es2022"] (needed for async iterables and modern JS features used by the LM API)

2. Add PSU Connection Settings

Add these configuration properties to package.json under contributes.configuration:

{
  "poshProTools.psu.url": {
    "type": "string",
    "default": "http://localhost:5000",
    "description": "URL of the PowerShell Universal server"
  },
  "poshProTools.psu.appToken": {
    "type": "string",
    "default": "",
    "description": "App token for authenticating with the PowerShell Universal APIs, including the /mcp/ surface"
  }
}

Update src/settings.ts to load these values:

psu: {
    url: configuration.get<string>("psu.url", "http://localhost:5000"),
    appToken: configuration.get<string>("psu.appToken", "")
}

3. PSU API Client (src/mcp/psuApiClient.ts)

Create an HTTP client that wraps the PSU MCP documentation and discovery API.

You MUST:

• Use the axios dependency already available in the project (or node-fetch which is also available)
• Accept URL and appToken from settings
• Set the Authorization header as Bearer <appToken> on every request
• Implement methods for the documentation namespace under /mcp/:
  • getDocumentationIndex() → GET /mcp/
  • getEndpointsReference(filter?: string) → GET /mcp/endpoints
  • getScriptsReference(filter?: string) → GET /mcp/scripts
  • getAppsReference(filter?: string) → GET /mcp/apps
  • getModuleReference(moduleName?: string) → GET /mcp/modules
  • getCmdletReference(moduleName?: string, cmdletName?: string) → GET /mcp/cmdlets
  • getDebugGuidance() → GET /mcp/debugging
  • getScopeGuidance() → GET /mcp/scopes
  • getCodingPractices() → GET /mcp/practices
  • getConfigReference(section?: string) → GET /mcp/config
• Implement methods for the discovery namespace under /mcp/discovery/:
  • getEndpointDiscovery(nameOrRoute?: string) → GET /mcp/discovery/endpoints
  • getScriptDiscovery(nameOrId?: string) → GET /mcp/discovery/scripts
  • getAppDiscovery(nameOrRoute?: string) → GET /mcp/discovery/apps
  • getModuleDiscovery(moduleName?: string) → GET /mcp/discovery/modules
  • getCmdletDiscovery(moduleName?: string, cmdletName?: string) → GET /mcp/discovery/cmdlets
• Handle errors gracefully — return structured error responses, never throw unhandled
• Validate the URL format before making requests (prevent SSRF — only allow configured host)
• Keep the /mcp/ namespace documentation-oriented and discovery-oriented only. Do NOT mix operational mutation routes into /mcp/.

If PSU does not natively expose /mcp/, the extension MUST build that documentation and discovery surface from the management APIs and bundled docs internally, but it MUST preserve the /mcp/ conceptual structure in the design and output.

CRITICAL Security Requirements:

• You MUST NOT allow arbitrary URLs in API requests. The base URL MUST come exclusively from the configured poshProTools.psu.url setting. You MUST NOT concatenate user-provided path segments without validation.
• You MUST use parameterized URL construction (e.g., new URL(path, baseUrl)) rather than string concatenation to prevent path traversal.
• You MUST NOT log or expose the appToken in output channels, error messages, or telemetry.
• You MUST validate HTTP responses before parsing to prevent JSON injection.

4. Tool Base Class (src/mcp/tools/toolBase.ts)

Create a base class that all PSU tools extend:

import * as vscode from 'vscode';
import { PsuApiClient } from '../psuApiClient';

export abstract class PsuToolBase<T> implements vscode.LanguageModelTool<T> {
    constructor(protected readonly apiClient: PsuApiClient) {}

    abstract invoke(
        options: vscode.LanguageModelToolInvocationOptions<T>,
        token: vscode.CancellationToken
    ): vscode.ProviderResult<vscode.LanguageModelToolResult>;

    prepareInvocation?(
        options: vscode.LanguageModelToolInvocationPrepareOptions<T>,
        token: vscode.CancellationToken
    ): vscode.ProviderResult<vscode.PreparedToolInvocation>;
}

5. Tool Implementations

Each tool MUST:

• Extend PsuToolBase<T> where T is the input schema type
• Return a LanguageModelToolResult with content formatted as Markdown documentation
• Include prepareInvocation with confirmation messages for any mutating operations (e.g., runScriptTool)
• Handle the case where PSU is not connected (return a helpful error message)
• Prefer the /mcp/ documentation namespace for read-only documentation requests so documentation answers stay separate from operational API behavior
• Use a cached module and cmdlet index for documentation lookups so module exploration is effectively immediate after the first load
• Use /mcp/discovery/ for agent-facing signature and schema retrieval whenever the agent needs to generate code, not just summarize docs

Tool Definitions for package.json

You MUST register tool contributions in package.json under contributes.languageModelTools:

{
  "contributes": {
    "languageModelTools": [
      {
        "name": "psu_connect",
        "displayName": "Connect to PowerShell Universal",
        "modelDescription": "Connects to a PowerShell Universal server instance and verifies the connection is healthy. Use this tool before using other PSU tools.",
        "inputSchema": {}
      },
      {
        "name": "psu_list_endpoints",
        "displayName": "List PSU API Endpoints",
        "modelDescription": "Lists all REST API endpoints registered on the PowerShell Universal server, including their URL routes, HTTP methods, documentation, and links to agent discovery metadata. Use this to understand what APIs are available on the PSU server before drilling into endpoint signatures with the discovery surface.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "filter": {
              "type": "string",
              "description": "Optional filter to search endpoints by URL pattern or name"
            }
          }
        }
      },
      {
        "name": "psu_list_scripts",
        "displayName": "List PSU Scripts",
        "modelDescription": "Lists all automation scripts registered on the PowerShell Universal server, including their names, schedules, parameters, and last run status. Use this to understand what automation is available.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "filter": {
              "type": "string",
              "description": "Optional filter to search scripts by name"
            }
          }
        }
      },
      {
        "name": "psu_list_apps",
        "displayName": "List PSU Apps & Dashboards",
        "modelDescription": "Lists all dashboard apps registered on the PowerShell Universal server, including their names, base URLs, frameworks, and components used. Use this to understand the UI applications hosted on PSU.",
        "inputSchema": {}
      },
      {
        "name": "psu_get_cmdlet_help",
        "displayName": "Get PSU Cmdlet Help",
        "modelDescription": "Retrieves detailed documentation for PowerShell Universal cmdlets and module exports (New-PSUEndpoint, New-PSUScript, New-UDApp, etc.). Returns fast module overviews, syntax, parameter descriptions, aliases, usage examples, and discovery metadata pointers for code generation. Use this when you need to understand which cmdlets a PSU module exposes or how to use a specific PSU cmdlet.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "cmdletName": {
              "type": "string",
              "description": "The name of the PSU cmdlet to get help for (e.g., 'New-PSUEndpoint', 'New-UDApp')"
            },
            "topic": {
              "type": "string",
              "description": "A topic to search cmdlets by (e.g., 'dashboard', 'endpoint', 'script')"
            }
          }
        }
      },
      {
        "name": "psu_get_config",
        "displayName": "Get PSU Configuration",
        "modelDescription": "Retrieves PowerShell Universal platform configuration including environments, variables, roles, authentication settings, and server information. Use this to understand the PSU server setup.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "section": {
              "type": "string",
              "enum": ["environments", "variables", "roles", "settings", "modules", "all"],
              "description": "Which configuration section to retrieve"
            }
          }
        }
      },
      {
        "name": "psu_run_script",
        "displayName": "Run PSU Script",
        "modelDescription": "Executes a registered script on the PowerShell Universal server by name or ID. Returns the job output. This is a mutating operation that will execute code on the server.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "scriptNameOrId": {
              "type": "string",
              "description": "The name or numeric ID of the script to execute"
            },
            "parameters": {
              "type": "object",
              "description": "Optional parameters to pass to the script"
            }
          },
          "required": ["scriptNameOrId"]
        }
      }
    ]
  }
}

CRITICAL: The modelDescription fields are what Copilot uses to decide when to invoke each tool. You MUST write these descriptions to be precise, contextual, and action-oriented. They MUST clearly state when each tool should be used and what information it provides.

6. MCP Server Definition Provider (src/mcp/mcpServerProvider.ts)

Register an McpServerDefinitionProvider that dynamically returns an McpHttpServerDefinition pointing at the PSU /mcp/ server surface when a connection is configured and active.

import * as vscode from 'vscode';
import { load } from '../settings';

export class PsuMcpServerProvider implements vscode.McpServerDefinitionProvider<vscode.McpHttpServerDefinition> {
    private _onDidChange = new vscode.EventEmitter<void>();
    readonly onDidChangeMcpServerDefinitions = this._onDidChange.event;

    notifyChanged() {
        this._onDidChange.fire();
    }

    provideMcpServerDefinitions(
        token: vscode.CancellationToken
    ): vscode.ProviderResult<vscode.McpHttpServerDefinition[]> {
        const settings = load();
        if (!settings.psu.url || !settings.psu.appToken) {
            return [];
        }
        // Only return a server definition if PSU is configured
        return [
            new vscode.McpHttpServerDefinition(
                'PowerShell Universal',
            vscode.Uri.parse(`${settings.psu.url}/mcp/`),
                { 'Authorization': `Bearer ${settings.psu.appToken}` }
            )
        ];
    }

    resolveMcpServerDefinition(
        server: vscode.McpHttpServerDefinition,
        token: vscode.CancellationToken
    ): vscode.ProviderResult<vscode.McpHttpServerDefinition> {
        return server;
    }
}

NOTE: The McpHttpServerDefinition approach only works if the PSU server itself exposes an MCP-compatible HTTP endpoint. If PSU does NOT have native MCP support, you MUST omit the McpServerDefinitionProvider registration and rely solely on the vscode.lm.registerTool() approach (which does NOT require PSU to speak MCP). You MUST check whether the PSU version supports /mcp/ before registering. If it does not, the LM tools alone provide the documentation server experience, but the design MUST still treat /mcp/ as the dedicated documentation and discovery namespace.

7. Extension Registration (src/extension.ts)

Update the activate function to register the MCP tools and provider:

// After existing initialization code, add:
import { PsuApiClient } from './mcp/psuApiClient';
import { PsuMcpServerProvider } from './mcp/mcpServerProvider';
import { ConnectTool } from './mcp/tools/connectTool';
import { ListEndpointsTool } from './mcp/tools/listEndpointsTool';
import { ListScriptsTool } from './mcp/tools/listScriptsTool';
import { ListAppsTool } from './mcp/tools/listAppsTool';
import { GetCmdletHelpTool } from './mcp/tools/getCmdletHelpTool';
import { GetConfigTool } from './mcp/tools/getConfigTool';
import { RunScriptTool } from './mcp/tools/runScriptTool';

// In activate():
const psuSettings = load();
const psuApiClient = new PsuApiClient(psuSettings.psu.url, psuSettings.psu.appToken);

// Register LM tools
context.subscriptions.push(vscode.lm.registerTool('psu_connect', new ConnectTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_list_endpoints', new ListEndpointsTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_list_scripts', new ListScriptsTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_list_apps', new ListAppsTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_get_cmdlet_help', new GetCmdletHelpTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_get_config', new GetConfigTool(psuApiClient)));
context.subscriptions.push(vscode.lm.registerTool('psu_run_script', new RunScriptTool(psuApiClient)));

// Register MCP server definition provider (only if PSU supports native MCP)
const mcpProvider = new PsuMcpServerProvider();
context.subscriptions.push(vscode.lm.registerMcpServerDefinitionProvider('psu-mcp', mcpProvider));

// Listen for configuration changes to update the API client
context.subscriptions.push(
    vscode.workspace.onDidChangeConfiguration(e => {
        if (e.affectsConfiguration('poshProTools.psu')) {
            const newSettings = load();
            psuApiClient.updateConnection(newSettings.psu.url, newSettings.psu.appToken);
            mcpProvider.notifyChanged();
        }
    })
);

8. Documentation Content Strategy

The tools MUST return documentation-quality content formatted as Markdown. The MCP server is a documentation server first, not just a transport wrapper. All documentation-oriented content SHOULD conceptually map to /mcp/ sections so it is obvious which resources are docs and which are operational APIs.

When the AI asks "what endpoints does this PSU server have?", the psu_list_endpoints tool should return something like:

## PowerShell Universal API Endpoints

### GET /api/users
- **Description**: Returns a list of all users
- **Authentication**: Required (Role: Administrator)
- **Environment**: PowerShell 7.4

### POST /api/orders
- **Description**: Creates a new order
- **Authentication**: Required (Role: Operator)
- **Parameters**: `$Body` (JSON)
- **Environment**: PowerShell 7.4

... (all registered endpoints)

For psu_get_cmdlet_help, the tool can either:

1. Call the PSU API to get available cmdlets and their help content (if PSU exposes this), OR
2. Embed/bundle the PSU cmdlet documentation from the public docs at docs.powershelluniversal.com as static content the tool returns

You SHOULD prefer option 1 (dynamic from server) when available, falling back to option 2.

9. Documentation Sections and Fast Reference Design

The documentation server MUST expose clear sections under /mcp/ for at least:

• endpoints — endpoint documentation summaries and usage guidance
• scripts — script inventory documentation and usage guidance
• apps — app and dashboard documentation and usage guidance
• modules — concise module overviews, exported cmdlets, aliases, dependencies, and common scenarios
• cmdlets — fast cmdlet lookup by module, verb-noun name, alias, and topic
• debugging — breakpoints, tracing, logs, troubleshooting flow, and inspection guidance
• scopes — PowerShell scope behavior, PSU runspace behavior, and how state flows across jobs, endpoints, and apps
• practices — common coding practices, recommended patterns, error handling, output shapes, naming, and security guidance
• config — platform configuration guidance for environments, variables, roles, authentication, and settings

The server MUST also expose discovery sections under /mcp/discovery/ for at least:

• endpoints — machine-readable endpoint signatures for agents
• scripts — machine-readable script invocation and parameter signatures
• apps — machine-readable app page, route, and component signatures
• modules — machine-readable module export and dependency signatures
• cmdlets — machine-readable cmdlet signatures, parameters, output shape, and examples

The modules and cmdlets sections MUST be optimized for very fast understanding:

• Build a compact in-memory documentation index keyed by module name, cmdlet name, alias, and topic
• Store short summaries, important parameters, and related cmdlets in the index so the agent does not need to fetch full raw help for every question
• Prefer precomputed manifests, help snapshots, or cached normalized metadata over repeated ad hoc parsing
• Return terse, high-signal summaries first, with deeper help available on demand

The discovery sections MUST be optimized for code generation:

• mcp/discovery/endpoints MUST return enough structured information for an agent to generate a correct call site or PowerShell handler implementation, including route, method, auth requirements, path params, query params, request body schema, response schema, examples, the expected PowerShell function or endpoint signature, and any related PSU cmdlets or helper functions
• Discovery payloads SHOULD be deterministic and schema-like so an agent can treat them like Swagger or OpenAPI for Copilot agents
• Documentation endpoints MAY be prose-rich, but discovery endpoints MUST stay compact, structured, and generation-friendly

The debugging, scopes, and practices sections MUST be treated as first-class documentation, not incidental notes. They should be easy for an AI agent to retrieve directly when asked questions about debugging PowerShell Universal code, understanding scope behavior, or following common repository and module coding practices.

Testing Guidance

• You MUST verify that each tool registers correctly and appears in Copilot's tool list
• You MUST verify that tools handle the "PSU not configured" case gracefully (no URL or token set)
• You MUST verify that tools handle the "PSU not reachable" case gracefully (server down)
• You MUST verify that the McpServerDefinitionProvider returns an empty array when PSU is not configured
• You MUST verify that configuration changes (URL, token) are picked up without requiring extension restart
• You MUST verify that the documentation and discovery surface remains clearly namespaced under /mcp/ and is not confused with operational APIs
• You MUST verify that module and cmdlet lookups are served from a fast cache or normalized index rather than repeated full-doc scans
• You MUST verify that /mcp/discovery/endpoints returns enough signature metadata for an agent to generate endpoint integration code without additional manual lookup

Constraints

• You MUST NOT add any new npm dependencies beyond what is already in package.json. Use axios (already present) for HTTP requests.
• You MUST NOT modify the existing named-pipe communication in PowerShellService — MCP is additive, not a replacement.
• You MUST preserve all existing extension functionality — this is purely an addition.
• You MUST follow the existing code style (CommonJS imports, class-based services, etc.).
• You MUST NOT hardcode any PSU server URLs or credentials in source code.

Success Criteria

1. After configuring poshProTools.psu.url and poshProTools.psu.appToken, a user can ask Copilot questions like:
   • "What API endpoints are registered on my PSU server?"
   • "What scripts are available on my PowerShell Universal instance?"
   • "Show me the documentation for New-PSUEndpoint"
   • "What dashboards are running on my PSU server?"

• "What cmdlets does this PSU module export?"
• "How do scopes behave in PSU scripts and endpoints?"
• "What are the recommended debugging and coding practices for this module?"
• "Show me the discovery signature for this endpoint so I can write the client code"

2. Copilot automatically invokes the appropriate PSU tool to answer these questions
3. The PSU server appears as a context source, similar to how Context7 provides library documentation
4. The documentation and discovery surface is clearly rooted at /mcp/ so it is not confused with the rest of the PSU APIs
5. All tools work without requiring a separate MCP server process

[Omzig]

closing:

• Add MCP Support powershell-pro-tools#153
• Docat0209 had a good comment: Add MCP Support powershell-pro-tools#153 (comment)