PowerShell と連携するためのモデルコンテキストプロトコルサーバー。このサーバーは、PowerShell コマンドの実行、システム情報の取得、モジュールの管理などを行うツールを提供します。
Node.js 18歳以上
PowerShell 5.1 または PowerShell Core 7+
Related MCP server: Command Executor MCP Server
依存関係をインストールします:
npm installプロジェクトをビルドします。
npm run build設定を編集: $HOME/Library/Application\ Support/Claude/claude_desktop_config.json
mcpServers に追加:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}設定を編集: $HOME/Library/Application\ Support/Code/User/settings.json
設定に追加:
"mcp": {
"servers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}設定を編集: $HOME/.cursor/mcp.json
mcpServers に追加:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}この PowerShell MCP サーバーは、次のツールを提供します。
PowerShell コマンドを実行して結果を取得します。
Parameters:
- command (string): PowerShell command to execute使用例:
execute_ps(command: "Get-Process | Select-Object -First 5")OS の詳細、プロセッサ、メモリ、PowerShell のバージョンなど、詳細なシステム情報を取得します。
Parameters: None使用例:
get_system_info()インストールされているすべての PowerShell モジュールを、名前、バージョン、タイプなどの詳細とともに一覧表示します。
Parameters: None使用例:
list_modules()構文、パラメーター、例など、特定の PowerShell コマンドの詳細なヘルプを取得します。
Parameters:
- command (string): PowerShell command to get help for使用例:
get_command_help(command: "Get-Process")PowerShell コマンドを名前またはパターンで検索します。
Parameters:
- search (string): Search term for PowerShell commands使用例:
find_commands(search: "Process")オプションのパラメータを使用して PowerShell スクリプト ファイルを実行します。
Parameters:
- scriptPath (string): Path to the PowerShell script file
- parameters (string, optional): Optional parameters to pass to the script使用例:
run_script(scriptPath: "/path/to/script.ps1", parameters: "-Name 'Test' -Value 123")開発モードで実行するには:
npm run dev独自の PowerShell ツールを追加するには:
src/index.tsを編集する
registerTools()メソッドで新しいツールを追加する
既存のパターンに従って一貫したエラー処理を行います
npm run buildでビルドする
// In the registerTools() method:
this.server.tool(
"my_ps_tool",
{
param1: z.string().describe("Description of parameter 1"),
param2: z.number().optional().describe("Optional numeric parameter"),
},
async ({ param1, param2 }) => {
try {
// Your PowerShell command
const command = `Your-PowerShell-Command -Param1 "${param1}" ${param2 ? `-Param2 ${param2}` : ''}`;
const { stdout, stderr } = await execAsync(`powershell -Command "${command.replace(/"/g, '\\"')}"`);
if (stderr) {
return {
isError: true,
content: [
{
type: "text" as const,
text: `Error in my_ps_tool: ${stderr}`,
},
],
};
}
return {
content: [
{
type: "text" as const,
text: stdout,
},
],
};
} catch (error) {
return {
isError: true,
content: [
{
type: "text" as const,
text: `Error in my_ps_tool: ${(error as Error).message}`,
},
],
};
}
}
);このサーバーはシステム上で直接PowerShellコマンドを実行します
コマンドはMCPサーバーを実行しているプロセスと同じ権限で実行されます
破壊的な操作を公開する場合は注意してください
機密コマンドの追加検証の実装を検討する
PowerShell実行ポリシーの制限
スクリプトの実行を許可するには、PowerShell 実行ポリシーを調整する必要があるかもしれません。
ローカルスクリプトを許可するには、 Set-ExecutionPolicy RemoteSigned -Scope CurrentUserを使用します。
パスが見つからないエラー
ファイルパスが絶対パスか、作業ディレクトリに対して適切な相対パスであることを確認する
OSに応じて適切なパス区切り文字を使用してください
コマンドが見つからないエラー
一部のコマンドでは特定のモジュールのインストールが必要になる場合があります
必要なモジュールをインストールするには、 Install-Module ModuleNameを使用します。
マサチューセッツ工科大学
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | PowerShell command to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | Search term for PowerShell commands |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | PowerShell command to get help for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | No | Optional parameters to pass to the script | |
| scriptPath | Yes | Path to the PowerShell script file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0execute_psfind_commandsget_command_helpget_system_infolist_modulesrun_scriptScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: execute_ps runs commands, find_commands searches for commands, get_command_help provides documentation, get_system_info retrieves system data, list_modules shows available modules, and run_script executes script files. The verbs and nouns clearly differentiate their functions.
All tool names follow a consistent snake_case verb_noun pattern (e.g., execute_ps, find_commands, get_command_help). The naming is uniform throughout with no deviations in style or convention.
With 6 tools, the count is reasonable for a PowerShell server, covering core operations like command execution, help, and system info. It might benefit from additional tools for more advanced PowerShell features, but it's well-scoped for basic functionality.
The tools cover essential PowerShell operations like executing commands, getting help, and listing modules, but there are notable gaps such as no tools for managing processes, services, or files, which are common in PowerShell workflows. The surface is functional but incomplete for full domain coverage.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.